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

From: "Ingemar Johansson S" <[email-masked]>
Date: Fri, 13 Nov 2009 03:00:20 +0100

Hi

I have raised this concern earlier on this list but I do this again just to make sure that this does not fall between the chairs.
The proposed "strawman" BoF charter discusses TCP. I would like the group to consider IP as the common denominator, the motivation can be found at.
http://www.ietf.org/mail-archive/web/re-ecn/current/msg00410.html 

In short the work done in ConEx should be able to apply on UDP as well as TCP. Other transports of interest may be SCTP and DCCP.

/Ingemar
=================================
INGEMAR JOHANSSON  M.Sc. 
Senior Research Engineer 

Ericsson AB
Multimedia Technologies
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]
www.ericsson.com 
Visit http://labs.ericsson.com !
=================================

---

From: bo zhou <[email-masked]>
Date: Fri, 13 Nov 2009 10:09:54 +0800

I believe Ingemar's suggestion is reasonable.
Hope the ConEx WG can consider all transport protocols rather than TCP only.

Regards,

Bo Zhou
China Mobile

On Fri, Nov 13, 2009 at 10:00 AM, Ingemar Johansson S <
[email-masked]> wrote:

> Hi
>
> I have raised this concern earlier on this list but I do this again just to
> make sure that this does not fall between the chairs.
> The proposed "strawman" BoF charter discusses TCP. I would like the group
> to consider IP as the common denominator, the motivation can be found at.
> In short the work done in ConEx should be able to apply on UDP as well as
> TCP. Other transports of interest may be SCTP and DCCP.
>
> /Ingemar
> _______________________________________________
> re-ECN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/re-ecn
>

-- 
Regards,

Bo Zhou
China Mobile

---

From: <[email-masked]>
Date: Fri, 13 Nov 2009 09:21:47 -0000

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. However each transport will add significantly to the time it takes the WG to produce usable output. 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.

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

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

·         Then move onto transports such as SCTP and DCCP once we have evidence of how the TCP implementation is going.

Given the current approach of the IESG is to try and limit the scope of charters in order to get results more quickly we are going to have to choose a point to divide the above list into current and future charters. The deciding factor will be to some extent the number of people prepared to work on a given item. Personally speaking I am torn between putting the split after TCP (which will allow us to make very rapid progress) and after RTP (which may well become very significant in the near future).

Toby

____________________________________________________________________ 
Toby Moncaster, Senior Researcher, Network Infrastructure Practice
B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 7918 901170 

 

From: [email-masked] [mailto:[email-masked]] On Behalf Of bo zhou
Sent: 13 November 2009 02:10
To: Ingemar Johansson S
Cc: [email-masked]
Subject: Re: [re-ECN] Other transports than TCP in charter

Regards,

Bo Zhou

China Mobile

On Fri, Nov 13, 2009 at 10:00 AM, Ingemar Johansson S <[email-masked]> wrote:

Hi

/Ingemar

Ericsson AB
Multimedia Technologies
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]
www.ericsson.com <http://www.ericsson.com/> 
Visit http://labs.ericsson.com <http://labs.ericsson.com/>  !
=================================
_______________________________________________
re-ECN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/re-ecn

-- 
Regards,

Bo Zhou
China Mobile

---

From: John Leslie <[email-masked]>
Date: Fri, 13 Nov 2009 07:00:16 -0500

[email-masked] <[email-masked]> 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.

   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.

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

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

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

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

--
John Leslie <[email-masked]>

---

From: <[email-masked]>
Date: Fri, 13 Nov 2009 12:06:35 -0000

> -----Original Message-----
> From: John Leslie [mailto:[email-masked]]
> Sent: 13 November 2009 12:00
> To: Moncaster,T,Toby,DEE1 R
> Cc: [email-masked]

We may be agnostic about what is right, but we may have views about what
is wrong (in other words some things may be demonstrably wrong like
significantly under-estimating the forward congestion which will reduce
the utility of conex).

> >   into their transport of choice.

The key thing here is at what point should the path congestion
information you have be considered stale and how accurately should you
be trying to measure congestion

>    Is it clear that we need to define _any_ "protocol extensions"

Well, it depends on how accurate you want to be. Currently ECN in TCP is
designed to effectively mask multiple congestion signals in a single RTT
since TCP will only react once anyway. For conex to be accurate we
really need to know about EVERY CE mark. And our simulations suggest in
any network with lots of short lived flows it is not uncommon to get
multiple marks in a RTT.

> to signal "congestion expected".

So would I, but somehow even the easiest things at the IETF seem to grow
in complexity!

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 13 Nov 2009 07:24:35 +0000

Bo, Ingemar,

I want to manage expectations here.

ConEx is ambitious, because it tries to shoe-horn something radically
different into the interoperability layer (IP) that everything else
builds over or under. During the design of re-ECN, every time we realised
there was a new constraint (e.g. a security attack), it often took weeks
to find a new design that still met all the other constraints. [We should
document all the design constraints - I'm v willing to help with
that.]

The degrees of freedom are really minimal down in IP. You have to seek
out each little crack, but then you can't just pop the protocol in. You
have to knock it in hard with a heavy hammer.

So far the number of minds working on this has been small: my team plus a
number of researchers devising attacks on the protocol. Once that number
grows, more constraints may well be found. I sincerely promise we have
tried to find them all, but... a lethal constraint might arise.

Therefore I believe we should charter to:

a) specify the base ConEx protocol in IP

b) provide design guidance for any ConEx transport

(including with no feedback at all*).

c) specify a ConEx transport extension for TCP

d) specify a minimum of n other transport extensions in detail, where
n=0

[* = If we adopt re-ECN, there are already guidelines in
draft-briscoe-tsvwg-re-ecn S.6.2.1 on how to do re-ECN with no feedback
at all (ie. pure UDP in datagram mode) or very infrequent feedback. This
is important, because we have to support re-ECN under transports like

* digital fountain, which uses FEC and no feedback.

* or DNS over UDP.

* I have also already specified a form of re-ECN for an inelastic
transport (see ref to re-PCN in S.6.2.2).]

Once we've written a full spec for TCP and we've covered pure UDP (as a
design guideline in the spec for ConEx in IP), this means we've covered
the transports that are the "host requirements" for the
Internet.

I think n=0 makes sense for the charter, in case we come across a big
problem and have to stop at the first hurdle. This doesn't stop us doing
more transports within the w-g; we just don't charter to *have* to do
them.

There is an argument for n=1: ie. we specify TCP and one example from
another extreme of the design space. That would give comfort that ConEx
is extensible. I wouldn't argue against n=1, but I'd prefer us to try to
do TCP first.

If we decided n=1, I would suggest ConEx in RTP/RTCP over UDP first, but
only for unicast.

Bob

BTW, I tried to show the transport design space over re-ECN in my talk to
ICCRG in Stockholm in Jul'09. See slide 19 of
<
http://bobbriscoe.net/presents/0907ietf/#0907iccrg>. Apologies, I
omitted LEDBAT from that slide.

At 02:09 13/11/2009, bo zhou wrote:

I believe Ingemar's suggestion
is reasonable.

Hope the ConEx WG can consider all transport protocols rather than TCP
only.

Regards,

Bo Zhou

China Mobile

On Fri, Nov 13, 2009 at 10:00 AM, Ingemar Johansson S
<
[email-masked]> wrote:

Hi

I have raised this concern earlier on this list but I do this again
just to make sure that this does not fall between the chairs.

The proposed "strawman" BoF charter discusses TCP. I would
like the group to consider IP as the common denominator, the motivation
can be found at.

In short the work done in ConEx should be able to apply on UDP as
well as TCP. Other transports of interest may be SCTP and DCCP.

/Ingemar

INGEMAR JOHANSSON  M.Sc.

Senior Research Engineer

Ericsson AB

Multimedia Technologies

Labratoriegränd 11

971 28, Luleå, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

www.ericsson.com

Visit
http://labs.ericsson.com !

re-ECN mailing list

[email-masked]

--

Regards,

Bo Zhou

China Mobile

re-ECN mailing list

[email-masked]

________________________________________________________________

Bob
Briscoe,
BT Innovate & Design

---

From: ken carlberg <[email-masked]>
Date: Fri, 13 Nov 2009 09:24:41 -0500

Bob,

> I want to manage expectations here.

I'm positive the ADs are thrilled to read this :-)

The thing I (and probably Ingemar) would ideally like to see is a charter that doesn't preclude the introduction of proposed work involving transports other than TCP.  This is perhaps a question to the chairs/ADs, but would it be possible to have a charter that makes a more general statement about transport protocols, and then for now have a specific milestone that only identifies a work item for TCP and no other transport protocol?

the advantage in doing something like this is that if one of us were to come up with an idea that addresses UDP via RTP/RTCP, then we could introduce it to the group for their consideration without having to ask for a change in the charter.  And by the same token, by not listing other transports as a current milestone, we don't commit the proposed group to something that could be considered too much / too soon.

-ken

---

From: <[email-masked]>
Date: Fri, 13 Nov 2009 14:36:52 -0000

There may need to be some careful wordsmithing of the charter to have
one that isn't overly restrictive but which ensures we end up with a
realistic work stack. I am still torn, but I would perhaps favour
something in the charter like

"initially we will be concentrating on TCP but given the growing
importance of other transports these are not being explicitly excluded.
Specific milestones are set out below for TCP with the intention that as
these are met, effort can be moved to alternative transports" 

Or something along those lines anyway...

Toby

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of ken carlberg
> Sent: 13 November 2009 14:25
> To: Briscoe,RJ,Bob,XVR9 BRISCORJ R
> Cc: Ingemar Johansson S; [email-masked]
> The thing I (and probably Ingemar) would ideally like to see is a
> charter that doesn't preclude the introduction of proposed work
> involving transports other than TCP.  This is perhaps a question to
the
> chairs/ADs, but would it be possible to have a charter that makes a
> more general statement about transport protocols, and then for now
have
> a specific milestone that only identifies a work item for TCP and no
> other transport protocol?
> 
> the advantage in doing something like this is that if one of us were
to
> come up with an idea that addresses UDP via RTP/RTCP, then we could
> introduce it to the group for their consideration without having to
ask
> for a change in the charter.  And by the same token, by not listing
> other transports as a current milestone, we don't commit the proposed
> group to something that could be considered too much / too soon.
> 
> -ken
>

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 13 Nov 2009 16:08:16 +0100

Hi,

> The thing I (and probably Ingemar) would ideally like to see is a charter
> that doesn't preclude the introduction of proposed work involving
> transports other than TCP.  

Yes! Me too. Actually exposing congestion is something that works on IP layer. 
Then you might want to also specify how the algorithms should work on sender 
and  on receiver side to count congestion and estimate the right number of ce 
marks to send. But how you actually feedback the current state of your 
counter from the receiver to the sender is a minor thing. In TCP case it 
might be using the 3 ECN bit. In another protocol you simply use 3 or more 
other bits. Definitely you need some requirements how often you have to 
feedback this information and so on. But this you need for very transport 
protocol. 
And than furthermore the case were you have no feedback channel should be 
covered as well, anyway.
But finally how to react on congestion (with TCP congestion control or 
something else or not at all) is in my option out of scope.

> This is perhaps a question to the chairs/ADs, 
> but would it be possible to have a charter that makes a more general
> statement about transport protocols, and then for now have a specific
> milestone that only identifies a work item for TCP and no other transport
> protocol?
I still think that we can't excluse other protocols anyway. If the goal is to 
make the endsystem/user more responsible for their congestion (using some 
kind of congestion policing on ingress node) you need to have congestion 
exposure on very kind of traffic. Otherwise this gives one the chance to 
cheat.

Mirja

---

From: John Leslie <[email-masked]>
Date: Fri, 13 Nov 2009 10:17:47 -0500

> these are met, effort can be moved to alternative transports" 

   If I may, I'd like to retreat towards reality... AFAICT, the proposed
charter includes only one item related to transport layer:
] 
] o Specification of necessary CONEX features in TCP, for example to carry
]   congestion information from receiver to sender

   ... which, frankly, I'd be delighted to drop entirely, since how
to move "congestion information from receiver to sender" seems _entirely_
out-of-scope to me...

   However, perhaps we could instead say:
" 
" o Specification of necessary interfaces with transport protocols
"   including, but not limited to, TCP;

   (Of course, IMHO, "necessary interfaces" is an empty set... ;^)

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 13 Nov 2009 15:16:13 +0000

Ken,

That's what I hoped I had said - you've said it more clearly.

Bob

At 14:24 13/11/2009, ken carlberg wrote:
>the chairs/ADs, but would it be possible to have a charter that 
>makes a more general statement about transport protocols, and then 
>for now have a specific milestone that only identifies a work item 
>for TCP and no other transport protocol?
>
>to come up with an idea that addresses UDP via RTP/RTCP, then we 
>could introduce it to the group for their consideration without 
>having to ask for a change in the charter.  And by the same token, 
>by not listing other transports as a current milestone, we don't 
>commit the proposed group to something that could be considered too 
>much / too soon.
>
>-ken

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: John Leslie <[email-masked]>
Date: Fri, 13 Nov 2009 11:18:24 -0500

[email-masked] <[email-masked]> wrote:
> We may be agnostic about what is right, but we may have views about
> what is wrong (in other words some things may be demonstrably wrong
> like significantly under-estimating the forward congestion which will
> reduce the utility of conex).

   I don't think "significantly under-estimating" will necessarily
"reduce the utility" of CONEX. We should be able to define policing
in a manner which incrementally improves utility.

   In all probability, there will be significant non-CONEX-marked
traffic at any policing point, which may instead lead to "significant
over-estimating" of forward congestion. This IMHO should lead to
estimating "willingness to pay to upgrade" on the high side, which
may speed the upgrade process and certainly marks the traffic as
deserving a higher priority than unmarked traffic.

   "Significant under-estimating" OTOH will lead to low estimates of
"willingness to pay to upgrade", and possibly causing a lower priority
to be inferred.

   It does seem worthwhile for us to define what constitutes the "right"
amount to estimate; but I'm not sure it helps to jawbone about whether
an estimate is high or low.

> be trying to measure congestion

   Clearly, staleness corresponds to how far past one RTT you are.
Unfortunately, what "one RTT" actually means is less clear.

   IMHO, "how accurately you measure" congestion is a meaningless
concept unless we agree what "congestion" is -- which I don't believe
will ever happen.

> ... Currently ECN in TCP is designed to effectively mask multiple
> congestion signals in a single RTT since TCP will only react once
> anyway.

   I prefer not to comment on that: over-estimating should give you
"better" throughput; under-estimating "worse" -- pick your poison...

> For conex to be accurate we really need to know about EVERY CE mark.
> And our simulations suggest in any network with lots of short lived
> flows it is not uncommon to get multiple marks in a RTT.

   Agreed. But that's getting into how congestion is signaled to the
sender, which still feels out-of-scope to me...

> So would I, but somehow even the easiest things at the IETF seem to grow

   Indeed!

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 13 Nov 2009 16:29:24 +0000

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

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

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

> >   into their transport of choice.

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;

>    Is it clear that we need to define _any_ "protocol extensions"

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.

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

>other than TCP and UDP shouldn't be "critical path" to getting TCP

Cool

Bob

---

From: <[email-masked]>
Date: Sat, 14 Nov 2009 16:51:17 -0000

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: [email-masked] on behalf of Bob Briscoe
Sent: Fri 13/11/2009 16:29
To: John Leslie
Cc: [email-masked]
Subject: Re: [re-ECN] Other transports than TCP in charter

John,

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

Cool

Bob

---

From: Mirja Kühlewind <[email-masked]>
Date: Sun, 15 Nov 2009 01:36:36 +0100

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

I think dropper design is not in the scope of conex but we need to include 
requirements on how the networks ensures that endpoints are not cheating. 
There might be different ways beside a dropper like bob suggested e.g. 
controlling sender and receiver separately. And it might not be necessary  to 
come up with one concrete algorithm but constraints what needs to be done to 
ensure endpoints behaving right have to be part of the work.

---

From: John Leslie <[email-masked]>
Date: Sat, 14 Nov 2009 21:25:32 -0500

Bob Briscoe <[email-masked]> wrote:
> below to explain an important potential constraint
> on good design of ConEx transport extensions.
> 

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

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

> round trip.

   Agreed.

> I call this the principle of "Source 

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

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

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

> Some transports may never 'do' ConEx.

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

   OK.

> and sanction dishonest flows, preferably at the

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

> TCP?s, or one particular resource sharing regime 
> 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.

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

> packets, each with a different flow ID

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

> vulnerable to ?identity whitewashing?, where a 

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

> including an actual recommended approach to follow.

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

> stuff. And we should ensure there's management

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

> to have non-ECN-capable ones as well).

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

---

From: John Leslie <[email-masked]>
Date: Sat, 14 Nov 2009 21:31:21 -0500

[email-masked] <[email-masked]> wrote:
>  
> 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.

   Yes.

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

   I'm not sure I think there should be _any_ "transport work item"
defined for a CONEX WG.

   In practice, of course, we'll have to design some transport
implementations to test CONEX; but I don't see why we should place
prior restrictions on such implementations.

   (For one example, I think a totally non-smoothed reaction to
ECN congestion-experienced marks will prove sub-optimal.)

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Mon, 16 Nov 2009 10:16:44 +0100

Hi

As stated earlier I agree on the proposed approach below.

/Ingemar 

> From: Bob Briscoe [mailto:[email-masked]] 
> Sent: den 13 november 2009 16:16
> To: ken carlberg
> Cc: Ingemar Johansson S; bo zhou; [email-masked]
> >involving transports other than TCP.  This is perhaps a 
> question to the 
> >more general statement about transport protocols, and then 
> for now have 
> >the advantage in doing something like this is that if one of 
> us were to 
> >introduce it to the group for their consideration without 
> having to ask

---

From: bo zhou <[email-masked]>
Date: Wed, 18 Nov 2009 10:19:45 +0800

+1 support the proposed approach.

Regards,

Bo

-- 
Regards,

Bo Zhou
China Mobile