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

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

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