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

Hi Georgios,

DCCP already features better-than-TCP ECN feedback (see section 11.4 of RFC4340).

Each Ack Vector option clearly indicated the exact stream of CE-marks in the received packets. (And two distinct ACK vector options provide the ECN Nonce feedback).

Using that information, you can figure out the *exact* congestion volume of a DCCP stream, without reverting to any post-hoc heuristic.

But I believe Bob has already pointed out, that TCP is the only transport which is in scope with conex WG?

Richard Scheffenegger

> -----Original Message-----
> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]
> Sent: Donnerstag, 07. Juli 2011 14:10
> To: Scheffenegger, Richard; 'Bob Briscoe'
> Cc: conex@ietf.org
> Subject: RE: [conex] New draft(s) on TCP modifications for ConEx
> 
> 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:rs@netapp.com]
> > Sent: donderdag 7 juli 2011 13:56
> > To: Georgios Karagiannis; Bob Briscoe
> > Cc: conex@ietf.org
> > 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
> > rs@netapp.com
> > +43 1 3676811 3146 Office (2143 3146 - internal)
> > +43 676 654 3146 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:karagian@cs.utwente.nl]
> > > Sent: Donnerstag, 07. Juli 2011 12:51
> > > To: 'Bob Briscoe'
> > > Cc: conex@ietf.org
> > > Subject: Re: [conex] New draft(s) on TCP modifications for ConEx
> > >
> > > Hi Bob,
> > >
> > >
> > > Please see in line!
> > >
> > >
> > > > -----Original Message-----
> > > > From: Bob Briscoe [mailto:bob.briscoe@bt.com]
> > > > Sent: donderdag 7 juli 2011 11:28
> > > > To: Georgios Karagiannis
> > > > Cc: conex@ietf.org
> > > > Subject: Re: [conex] New draft(s) on TCP modifications for ConEx
> > > >
> > > > Georgios,
> > > >
> > > > >On 7/7/2011, "Georgios Karagiannis" <karagian@cs.utwente.nl>
> 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
> > > conex@ietf.org
> > > https://www.ietf.org/mailman/listinfo/conex