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

["Scheffenegger, Richard" <[e-mail]>]

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