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

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

Hi Richard,

Thanks for the information!


Best regards,
Georgios

> -----Original Message-----
> From: Scheffenegger, Richard [mailto:[e-mail]]
> Sent: donderdag 7 juli 2011 14:36
> To: Georgios Karagiannis; Bob Briscoe
> Cc: [e-mail]
> Subject: 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:[e-mail]]
> > Sent: Donnerstag, 07. Juli 2011 14:10
> > To: Scheffenegger, Richard; 'Bob Briscoe'
> > Cc: [e-mail]
> > 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:[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