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

[Bob Briscoe <[e-mail]>]

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