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

["Ingemar Johansson S" <[e-mail]>]

Hi

I believe that the alternative that no milestones are listed for non-TCP
flows is a good one. 
As regards to droppers, even though this is not the main focus I believe
this is the real hard nut to crack and it is probably here the issues
with e.g limited reporting frequency of RTCP may cause issues. I believe
that this is probably the reason why I push so hard hard for keeping
other transports than TCP in mind. One cannot rule out the possibility
that these issues may have impact on the protocol design. Hopefully
however it should only have an impact on the requirements on the
policers/droppers.

On another matter. The part I find most confusing this the
proterties/treament of long-lived vs short-lived flows. I guess I need
to do some RTFM here but it is possible that these matters are
thoroughly dicussed so that enough people understand it.

/Ingemar


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of [e-mail]
> Sent: den 15 november 2009 01:51
> To: [e-mail]
> Subject: re-ECN Digest, Vol 9, Issue 43
> 
> If you have received this digest without all the individual 
> message attachments you will need to update your digest 
> options in your list subscription.  To do so, go to 
> 
> https://www.ietf.org/mailman/listinfo/re-ecn
> 
> Click the 'Unsubscribe or edit options' button, log in, and 
> set "Get MIME or Plain Text Digests?" to MIME.  You can set 
> this option globally for all the list digests you receive at 
> this point.
> 
> 
> 
> Send re-ECN mailing list submissions to
> 	[e-mail]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.ietf.org/mailman/listinfo/re-ecn
> or, via email, send a message with subject or body 'help' to
> 	[e-mail]
> 
> You can reach the person managing the list at
> 	[e-mail]
> 
> When replying, please edit your Subject line so it is more 
> specific than "Re: Contents of re-ECN digest..."
> 
> 
> Today's Topics:
> 
>    1. Re:  Other transports than TCP in charter 
> ([e-mail])
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Sat, 14 Nov 2009 16:51:17 -0000
> From: <[e-mail]>
> Subject: Re: [re-ECN] Other transports than TCP in charter
> To: <[e-mail]>uk>,	<[e-mail]>
> Cc: [e-mail]
> Message-ID:
> 	
> <[e-mail]1
> .systemhost.net>
> 	
> Content-Type: text/plain;	charset="iso-8859-1"
> 
> 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
> 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> re-ECN mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/re-ecn
> 
> 
> End of re-ECN Digest, Vol 9, Issue 43
> *************************************
>