Re: [conex] New draft(s) on TCP modifications for ConEx

["Georgios Karagiannis" <[e-mail]>]

Hi Bob,

The goal of the solution provided in my I-D is that TFRC is used to
calculate the congestion exposure rate in a much simpler manner than the
one proposed by Re-ECN. The calculated congestion rate will be then
exposed into the IP network in a similar way as described in the
"conex-abstract-meth".

Richard already mentioned that by using TFRC the congestion exposure rate
can be calculated much easier than I thought. Thus instead of
calculating the congestion exposure rate from the TCP throughput, one
can just calculate that from the received pX directly.

So my congestion exposure solution is much much simpler than I thought.
Thus Richard thanks for this hint!

These changes will be included in the next version of the draft.

Best regards,
Georgios


On 7/7/2011, "Bob Briscoe" <[e-mail]> wrote:

>Georgios,
>
>I don't think it's fair to describe your draft as a solution.
>Whatever the protocol. Whatever the congestion 
>control algorithm. It achieves precisely nothing, except warming the processor.
>
>Your draft merely suggests a sender can calculate information it already has..
>
>
>Existing situation for any transport sender:
>- Congestion feedback information comes in to the 
>sender at rate pX (the loss event rate).
>- The sender uses this to drive the algorithm 
>that determines how it changes its rate X
>
>Your proposal
>- The sender measures the change in the rate X 
>every RTT and from this works out what p would 
>have caused this, using the equation for its own algorithm in reverse.
>- from p it can work out pX, the loss event rate
>
>Results:
>- the sender has worked out pX, which it already knew accurately at the start.
>- the CPU has got warmer.
>
>Therefore, as I said, this achieves precisely 
>nothing except increasing the amount of entropy in the Universe.
>
>
>
>Bob
>
>At 13:09 07/07/2011, Georgios Karagiannis wrote:
>>Hi Richard,
>>
>>You are right! The solution described in my draft only applies to transport
>>protocols that are using TFRC .
>>
>>So my proposal is:
>>Is it possible to combine our solutions, such that TCP based applications,
>>but also DCCP based applications can use Conex?
>>
>>Best regards,
>>Georgios
>>
>>
>>
>> > -----Original Message-----
>> > From: Scheffenegger, Richard [mailto:[e-mail]]
>> > Sent: donderdag 7 juli 2011 13:56
>> > To: Georgios Karagiannis; Bob Briscoe
>> > Cc: [e-mail]
>> > Subject: RE: [conex] New draft(s) on TCP modifications for ConEx
>> >
>> > Hi Georgios,
>> >
>> >
>> > If you choose to use formulas to estimate the transport rate, that formula
>> > obviously has to apply to the transport protocol used. TFRC is applicable
>>to
>> > DCCP CCID3/4, and perhaps to legacy TCP reno/newreno. However, all bets
>> > are off for *ANY* other transport (CBR VoIP over UDP / RTP).
>> >
>> > Furthermore, each of these transports has to have some form of feedback
>> > mechanism from the receiver to the sender, so that the sender can actually
>> > react to congestion. Thus, your scheme is implicitly completely reliant on
>> > whatever feedback is available from the transport.
>> >
>> > RTP, for example, will have very extensive feedback (much more extensive
>> > than what TCP, SCTP, DCCP can do) - see
>>http://tools.ietf.org/id/draft-ietf-
>> > avtcore-ecn-for-rtp-00.txt
>> >
>> >
>> > What Bob tried to point out is exactly that - your method applies a
>>specific,
>> > post-hoc method. This method implicitly relies on transport feedback
>> > already, but then simply appears to stuff all transports into a
>>TCP-friendly
>> > corset, which may not applicable at all.
>> >
>> >
>> > The goal of our drafts (accurate-ecn and conex-tcp-mods) is to address the
>> > critical part, where the transport receiver gives the *appropriate* (not
>>some
>> > estimated) congestion information back to the transport sender. With TCP,
>> > we are unfortunately very constrained due to the very widespread use (and
>> > also because TCP processing is poured into hardware these days), which
>> > severly limits what can be done in a backwards-compatible way.
>> >
>> > Best regards,
>> >
>> > Richard Scheffenegger
>> >
>> > NetApp
>> > [e-mail]
>> > [phone] Office (2143 3146 - internal)
>> > [phone] Mobile
>> > www.netapp.com
>> >
>> > EURO PLAZA
>> > Gebäude G, Stiege 7, 3.OG
>> > Am Euro Platz 2
>> > A-1120 Wien
>> >
>> >
>> >
>> > > -----Original Message-----
>> > > From: Georgios Karagiannis [mailto:[e-mail]]
>> > > Sent: Donnerstag, 07. Juli 2011 12:51
>> > > To: 'Bob Briscoe'
>> > > Cc: [e-mail]
>> > > Subject: Re: [conex] New draft(s) on TCP modifications for ConEx
>> > >
>> > > Hi Bob,
>> > >
>> > >
>> > > Please see in line!
>> > >
>> > >
>> > > > -----Original Message-----
>> > > > From: Bob Briscoe [mailto:[e-mail]]
>> > > > Sent: donderdag 7 juli 2011 11:28
>> > > > To: Georgios Karagiannis
>> > > > Cc: [e-mail]
>> > > > Subject: Re: [conex] New draft(s) on TCP modifications for ConEx
>> > > >
>> > > > Georgios,
>> > > >
>> > > > >On 7/7/2011, "Georgios Karagiannis" <[e-mail]> wrote:
>> > > > > >Regarding the beyond reasoning statement, it is better to not
>> > > discuss
>> > > > > >it via email, but face to face. Will you be in Quebec during the
>> > > next
>> > > > > >IETF meeting?
>> > > >
>> > > > I meant that your response was not engaging in the reasoning put to
>> > > you.
>> > > >
>> > > > You can go back and respond to the reasoning already given. But I
>> > > don't
>> > > need
>> > > > to say any more.
>> > > >
>> > > > My main point was that the whole idea of your draft goes round in a
>> > > loop
>> > > > that achieves nothing.
>> > > > You avoided this critical point and jumped to a detail (a detail
>> > > within
>> > > that loop
>> > > > that already achieves nothing).
>> > >
>> > > Georgios: I am not sure if this loop  applies to what is written in my
>> > > draft.
>> > >
>> > > >
>> > > > Now you are saying you meant something very different to what you
>> > > > had written (you now say the draft was about DCCP, but the title of
>> > > > your
>> > > draft
>> > > > says it is about TCP and DCCP isn't mentioned). Anyway, DCCP takes
>> > > you
>> > > off-
>> > > > charter instead  (see below).
>> > >
>> > > In the drafts I had not yet specified which transport protocol should
>> > > be used, what I have specified was that the congestion exposure can be
>> > > calculated using the TCP throughput formula used in TFRC (RFC5348).
>> > > And according to [RFC5348] "TFRC is a congestion control mechanism
>> > > designed for unicast flows operating in
>> > >    an Internet environment and competing with TCP traffic [FHPW00].
>> > >    Instead of specifying a complete protocol, this document simply
>> > >    specifies a congestion control mechanism that could be used in a
>> > >    transport protocol such as DCCP (Datagram Congestion Control
>> > >    Protocol) [RFC4340], in an application incorporating end-to-end
>> > >    congestion control at the application level, or in the context of
>> > >    endpoint congestion management [BRS99].", from [RFC5348].
>> > >
>> > > So I do not think that I was saying something in the previous email
>> > > that is different than what is stated in my draft.
>> > >
>> > >
>> > > >
>> > > > At 07:08 07/07/2011, Georgios Karagiannis wrote:
>> > > > >Do you mean that is off-charter because is using for feedback DCCP
>> > > > >& TFRC (RFC5348, RFC5622, RFC4342) instead of TCP?
>> > > >
>> > > > Yes.
>> > > >
>> > > > ConEx is primarily at the IP layer, but some transports need
>> > > > optional
>> > > changes
>> > > > to their feedback. The charter says we will focus on TCP first.
>> > >
>> > > Georgios: In the charter the following is mentioned:
>> > > "Today, the network may signal
>> > > congestion by ECN markings or by dropping packets, and the receiver
>> > > passes this information back to the sender in transport-layer
>> > > acknowledgements. The mechanism to be developed by the CONEX WG
>> > will
>> > > enable the sender to also relay the congestion information back into
>> > > the network in-band at the IP layer, such that the total level of
>> > > congestion is visible to all IP devices along the path, from where it
>> > > could, for example, be provided as input to traffic management." ,
>> > > from [Conex charter]
>> > >
>> > >
>> > > Further down the charter mentions:
>> > >
>> > > "Primary work items are:
>> > >
>> > > * An Informational document containing an abstract description of the
>> > > congestion exposure mechanism that is independent of specific
>> > > transport protocols and congestion information encoding techniques
>> > > needed for different IP protocol versions.
>> > >
>> > > * An Experimental specification of an IPv6 packet structure that
>> > > encapsulates CONEX information, defining a packet format and an
>> > > interpretation.
>> > >
>> > >
>> > > * An Experimental specification of a modification to TCP, for the
>> > > timely transport of congestion information from the destination to the
>> > > sender.", from [Conex charter]
>> > >
>> > >
>> > > By reading the first paragraph from above, I can  understand that
>> > > Conex WG will use transport-layer acknowledgement to pass the
>> > > congestion information (signalled by ECN markings or by dropping
>> > > packets to the receiver) from the receiver to the sender.
>> > > Thus any types of transport protocols can be used for this purpose
>> > > (e.g., TCP, DCCP).
>> > >
>> > >
>> > > By reading the third bullet from above,  I can understand that the
>> > > CONEX WG will primarily focus on TCP.
>> > >
>> > > However, to my understanding this does not imply that other types of
>> > > transport protocols, e.g. .,  DCCP, are off-charter.  This is in my
>> > > opinion not explicitly  mentioned in the charter.
>> > >
>> > > Could the WG chairs comment on this issues, see below:
>> > >
>> > > Conex needs transport protocols to carry congestion information from a
>> > > receiver to a sender.
>> > > Are transport protocols such as DCCP out of the Conex charter scope?
>> > >
>> > > >
>> > > > You are criticising a draft written to satisfy this charter
>> > > objective. You
>> > > are
>> > > > saying it is difficult to change the semantics of TCP header fields
>> > > (which
>> > > we
>> > > > are already chartered to do). So you propose everyone should have to
>> > > use
>> > > > DCCP in order to use ConEx. That would require every application in
>> > > the
>> > > > world that uses TCP to be changed to call DCCP instead, in order to
>> > > use
>> > > > ConEx. And most middleboxes (NATs, firewalls) would have to be
>> > > changed
>> > > > too.
>> > >
>> > > Georgios: Sorry Bob, but this is your interpretation.
>> > >
>> > > Another interpretation could be:
>> > > It is good to provide the means such that Conex is used in combination
>> > > with applications that are using not only TCP as a transport protocol,
>> > > but also the ones that are using DCCP as transport protocol.
>> > > Furthermore, start with a solution to calculate congestion,  in this
>> > > case the TFRC [RF5348], that is simple and does not imply many
>> > > standardization changes on the transport protocols using this
>> > > solution.
>> > > Moreover, note that I am in favour that a TCP based transport solution
>> > > should be specified in parallel.
>> > >
>> > > Best regards,
>> > > Georgios
>> > >
>> > >
>> > > _______________________________________________
>> > > conex mailing list
>> > > [e-mail]
>> > > https://www.ietf.org/mailman/listinfo/conex
>
>________________________________________________________________
>Bob Briscoe,                                BT Innovate & Design