Subject: [conex] Fwd: New Version Notification for draft-ietf-conex-tcp-modifications-02.txt

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 10 May 2012 19:31:30 +0200

Hi Matt, hi Jana,

I submitted a new version of the ConEx TCP Mod Draft. I believe you 
volunteered to review the document.

There are currently two ToDos left. One is about a more generic description 
how set the right number of credits regarding the congestion control that is 
used. I think, Matt, you had some idea here already. Maybe you can provide 
some feedback here as well.
The other one is the question if further action needs to be take if ConEx 
markings got lost. I guess I will post this question separately on the 
mailing list.

Thanks in advance,
Mirja

----------  Forwarded Message  ----------

Subject: New Version Notification for 
draft-ietf-conex-tcp-modifications-02.txt
Date: Thursday 10 May 2012, 19:26:08
From: [email-masked]
To: [email-masked]
CC: [email-masked]

A new version of I-D, draft-ietf-conex-tcp-modifications-02.txt has been 
successfully submitted by Mirja Kuehlewind and posted to the IETF repository.

Filename:	 draft-ietf-conex-tcp-modifications
Revision:	 02
Title:		 TCP modifications for Congestion Exposure
Creation date:	 2012-05-10
WG ID:		 conex
Number of pages: 14

Abstract:
   Congestion Exposure (ConEx) is a mechanism by which senders inform
   the network about the congestion encountered by previous packets on
   the same flow.  This document describes the necessary modifications
   to use ConEx with the Transmission Control Protocol (TCP).

The IETF Secretariat

-------------------------------------------------------

---

From: Ingemar Johansson S <[email-masked]>
Date: Fri, 18 May 2012 15:10:26 +0200

Hi

Thanks for a great effort to get this in order.

Some comments, even though I haven't had the time to follow all the details in ConEx I still hope they can be of some value. 

I have not scrutinized the computation of CEG and LEG  in detail but I follow the discussion and it makes sense. Question, has anybody done any simulation experiments on this ?

Comments/questions:
Section 4.1, last sentence: First I did not understand it at all but I believe that I get it now.. Maybe not important but perhaps one can rewrite it like
The CEG and LEG counters SHOULD be reset if any of these conditions occur:
1) One RTT since they was last decreased
2) One RTT after (loss?) recovery if no further congestion
Not sure if this makes things more simple... 

Section 4.2:
This is IMHO the most complicated part. I fail to understand why it is sufficient with a number of credits which is half the number of packet in flight. Is this some kind of educated estimate ?. Probably I need to get this explained better but there is a chance that other need it too.
As regards to the statement that credit marks are only needed in slow start. Cubic's cubic function may make it necessary to add extra credit marks to avoid the flows being penalized in the audit functions or?

Section 4.3:
One complicating matter in e.g LTE is that the audit function needs to be in the eNodeB, at handover the audit state will be lost unless it is communicated to the other eNodeB via the X2 interface. Nothing that needs mention in this document but it is worth mention anyway.

Section 5:
"The sender MUST NOT delay the ConEx signal more than one RTT" : This has implications for instance for WebRTC as it puts a strict requirement to feedback the actual congestion information in a timely manner. As of today the discussion in WebRTC is around feedback of rate request information rather than congetsion information. Again, nothing that needs to be mentioned in this doc but should probably be considered if the congetsion control WG for WebRTC is formed.

/Ingemar

Nits:
Page 8: "No congestion feedback information are available" --> "No congestion feedback information is available"

Page 9: " Thus these packet.."  --> " Thus these packets.."
"These packet" --> "These packets"
"unset" --> "reset" ?

Page 11: "contributed with this.." --> "contributed with his" ? 

> -----Original Message-----
> From: Mirja Kühlewind [mailto:[email-masked]] 
> Sent: den 10 maj 2012 19:32
> To: Matt Mathis; Janardhan Iyengar
> Cc: [email-masked]
> Subject: [conex] Fwd: New Version Notification for 
> I submitted a new version of the ConEx TCP Mod Draft. I 
> believe you volunteered to review the document.
> 
> There are currently two ToDos left. One is about a more 
> generic description how set the right number of credits 
> regarding the congestion control that is used. I think, Matt, 
> you had some idea here already. Maybe you can provide some 
> feedback here as well.
> The other one is the question if further action needs to be 
> take if ConEx markings got lost. I guess I will post this 
> question separately on the mailing list.
> 
> Thanks in advance,
> Mirja
> 
> 
> A new version of I-D, 
> draft-ietf-conex-tcp-modifications-02.txt has been

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 24 May 2012 11:42:00 +0200

Hi Ingemar,

thanks a lot for your feedback! See some comments inline...

Mirja

On Friday 18 May 2012 15:10:26 Ingemar Johansson S wrote:
> Some comments, even though I haven't had the time to follow all the details
> in ConEx I still hope they can be of some value.
>
> I have not scrutinized the computation of CEG and LEG  in detail but I
> follow the discussion and it makes sense. Question, has anybody done any
> simulation experiments on this ?
Not yet, but it's on my todo list.

>
> Comments/questions:
> Section 4.1, last sentence: First I did not understand it at all but I
> believe that I get it now.. Maybe not important but perhaps one can rewrite
> it like The CEG and LEG counters SHOULD be reset if any of these conditions
> occur: 1) One RTT since they was last decreased
Yes, makes sense. I'll rewrite.

>
> Section 4.2:
> This is IMHO the most complicated part. I fail to understand why it is
> sufficient with a number of credits which is half the number of packet in
> flight. Is this some kind of educated estimate ?. Probably I need to get
> this explained better but there is a chance that other need it too. As
> regards to the statement that credit marks are only needed in slow start.
> Cubic's cubic function may make it necessary to add extra credit marks to
> avoid the flows being penalized in the audit functions or?
The recommendations right now are only for Reno. There is a todo in the doc to 
have a more general recommendation here. Maybe having one for cubic would 
also make sense.
Regarding slow start, in fact all your packets in fight can get lost, right? 
But we assume if in the previous RTT no packets got lost, then number of 
packets in fight from the previous RTT should be safe to send. Only those 
packets that we send additionally in this RTT can get lost. In slow start we 
double the packets in flight every RTT, thus we risk to loose half the 
packets in flight. Is this understandable? May you have some hints how to 
rewrite this paragraph to make it better understandable!?

>
> Section 4.3:
> One complicating matter in e.g LTE is that the audit function needs to be
> in the eNodeB, at handover the audit state will be lost unless it is
> communicated to the other eNodeB via the X2 interface. Nothing that needs
> mention in this document but it is worth mention anyway.
In general it should be no problem if the audit looses the state (what can 
also happen because of e.g. re-routing). If the state could be transferred, I 
guess that's better. But this such be discussed in 
draft-kutscher-conex-mobile-03 (cc'ed Dirk). 
For the TCP modification draft there is still this open issue what to do if 
the state in the audit is incorrect, e.g. packets when ConEx marks get lost. 
I guess that's the same case from the perspective of the sender.

>
> Section 5:
> "The sender MUST NOT delay the ConEx signal more than one RTT" : This has
> implications for instance for WebRTC as it puts a strict requirement to
> feedback the actual congestion information in a timely manner. As of today
> the discussion in WebRTC is around feedback of rate request information
> rather than congetsion information. Again, nothing that needs to be
> mentioned in this doc but should probably be considered if the congetsion
> control WG for WebRTC is formed.
Very good remark. I monitor Congestion Control for WebRTC and try to keep this 
in mind.

>
> /Ingemar
>
>
> Nits:
> Page 8: "No congestion feedback information are available" --> "No
> congestion feedback information is available"
>

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: [email-masked]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------

---

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 24 May 2012 12:48:40 +0200

Hi

Comments inline where needed.

/Ingemar 

> From: Mirja Kuehlewind [mailto:[email-masked]] 
> Sent: den 24 maj 2012 11:42
> To: Ingemar Johansson S
> Cc: [email-masked]; Dirk Kutscher
> Subject: Re: [conex] Fwd: New Version Notification for 
> > Some comments, even though I haven't had the time to follow all the 
> > details in ConEx I still hope they can be of some value.
> >
> > follow the discussion and it makes sense. Question, has 
> anybody done 
> > any simulation experiments on this ?
> > believe that I get it now.. Maybe not important but perhaps one can 
> > rewrite it like The CEG and LEG counters SHOULD be reset if any of 
> > these conditions
> > sufficient with a number of credits which is half the 
> number of packet 
> > in flight. Is this some kind of educated estimate ?. 
> Probably I need 
> > to get this explained better but there is a chance that 
> other need it 
> > too. As regards to the statement that credit marks are only 
> needed in slow start.
> > Cubic's cubic function may make it necessary to add extra 
> credit marks 
> > to avoid the flows being penalized in the audit functions or?
> The recommendations right now are only for Reno. There is a 
> todo in the doc to have a more general recommendation here. 
> Maybe having one for cubic would also make sense.
> But we assume if in the previous RTT no packets got lost, 
> then number of packets in fight from the previous RTT should 
> be safe to send. Only those packets that we send additionally 
> in this RTT can get lost. In slow start we double the packets 
> in flight every RTT, thus we risk to loose half the packets 
> in flight. Is this understandable? May you have some hints 
> how to rewrite this paragraph to make it better understandable!?
Ahh.. Now I get it!, thanks, sounds very reasonable. Based on your explanation above the text makes sense. Don't have any good suggestion as regards to how to improve the text but perhaps if your explanation above can be included in the text ? (if it is needed).

> 
> >
> > Section 4.3:
> > One complicating matter in e.g LTE is that the audit 
> function needs to 
> > be in the eNodeB, at handover the audit state will be lost 
> unless it 
> > is communicated to the other eNodeB via the X2 interface. 
> Nothing that 
> > needs mention in this document but it is worth mention anyway.
> In general it should be no problem if the audit looses the 
> state (what can also happen because of e.g. re-routing). If 
> the state could be transferred, I guess that's better. But 
> this such be discussed in
> For the TCP modification draft there is still this open issue 
> what to do if the state in the audit is incorrect, e.g. 
> packets when ConEx marks get lost. 
Must admit that I have been with my head stuck in the sand for the last couple of months or so, have not had the time to read conex-mobile in detail, but you are right, something around this probably fits there (unless it is already mentioned of course)

> 
> >
> > Section 5:
> > "The sender MUST NOT delay the ConEx signal more than one 
> RTT" : This 
> > has implications for instance for WebRTC as it puts a strict 
> > requirement to feedback the actual congestion information 
> in a timely 
> > manner. As of today the discussion in WebRTC is around feedback of 
> > rate request information rather than congetsion information. Again, 
> > nothing that needs to be mentioned in this doc but should 
> probably be 
> > considered if the congetsion control WG for WebRTC is formed.
> Very good remark. I monitor Congestion Control for WebRTC and 
> try to keep this in mind.
Thanks, I will also try to follow the BoF discussion around "congetsion control WG for WebRTC". I am still not sure where ConEx might end up but it is very relevant for webRTC to consider it.

> > > From: Mirja Kühlewind 
> [mailto:[email-masked]]