Subject: [Iccrg] About the state of MulTFRC
From: [email-masked] (Michael Welzl)
Date: Sat Jul 28 13:40:52 2012

Hi,

Indeed that's very useful and good to know about, thanks!

Cheers,
Michael

On Jul 28, 2012, at 3:05 AM, Emmanuel Lochin wrote:

> Hi Michael,
>
> I read some comments concerning the complexity of the computation. For
> the sake of decreasing TFRC computational complexity, note that
> Guillaume Jourjon simply proposed a Newton algorithm to initialize the
> loss history structure. Compared to the standard implementation you
> could find in FreeBSD, the proposed method halves the # of iterations
> in the worst case scenario : see http://oatao.univ-toulouse.fr/211/
> for details. This does not solve everything but at least this is an
> improvement :)
>
> Cheers,
>
> Emmanuel
>
> On 28 July 2012 05:30, Michael Welzl <[email-masked]> wrote:
>> Hi,
>>
>> It's ages since the last time I posted something about MulTFRC (
>> http://heim.ifi.uio.no/~michawe/research/projects/multfrc/ 
>> index.html ) here.
>>
>> So I thought I'd send this message, to tell you all that we're  
>> still on the
>> case. The situation is - we got reviews, addressed all comments,  
>> EXCEPT for
>> the request to come up with a good fixed point version of our  
>> algorithm.
>> Note that the current draft can be implemented and used whenever  
>> floats are
>> available (normally in user-space).
>>
>> Developing a fixed point version has turned out to be  
>> muuuuuuuuuuuuuuuuch
>> harder than we thought. We're still working on it (right now I have  
>> a master
>> student who is looking into this), but it just takes it time.
>>
>> Cheers,
>> Michael
>>
>>
>> _______________________________________________
>> Iccrg mailing list
>> [email-masked]
>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
>
>
> -- 
> "This email and any attachments are confidential. They may contain  
> legally
> privileged information or copyright material. You should not read,  
> copy, use
> or disclose them without authorisation. If you are not an intended
> recipient, please contact us at once by return email and then delete  
> both
> messages. We do not accept liability in connection with computer  
> virus,
> data corruption, delay, interruption, unauthorised access or  
> unauthorised
> amendment. This notice should not be removed"

From: [email-masked] (Emmanuel Lochin)
Date: Sat Jul 28 11:02:55 2012
Subject: [Iccrg] About the state of MulTFRC
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <CAEsJsFmpq4M4sj+bL_hxKX=[email-masked]>

Hi Michael,

I read some comments concerning the complexity of the computation. For
the sake of decreasing TFRC computational complexity, note that
Guillaume Jourjon simply proposed a Newton algorithm to initialize the
loss history structure. Compared to the standard implementation you
could find in FreeBSD, the proposed method halves the # of iterations
in the worst case scenario : see http://oatao.univ-toulouse.fr/211/
for details. This does not solve everything but at least this is an
improvement :)

Cheers,

Emmanuel

On 28 July 2012 05:30, Michael Welzl <[email-masked]> wrote:
> Hi,
>
> It's ages since the last time I posted something about MulTFRC (
> http://heim.ifi.uio.no/~michawe/research/projects/multfrc/index.html ) here.
>
> So I thought I'd send this message, to tell you all that we're still on the
> case. The situation is - we got reviews, addressed all comments, EXCEPT for
> the request to come up with a good fixed point version of our algorithm.
> Note that the current draft can be implemented and used whenever floats are
> available (normally in user-space).
>
> Developing a fixed point version has turned out to be muuuuuuuuuuuuuuuuch
> harder than we thought. We're still working on it (right now I have a master
> student who is looking into this), but it just takes it time.
>
> Cheers,
> Michael
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

-- 
"This email and any attachments are confidential. They may contain legally
privileged information or copyright material. You should not read, copy, use
or disclose them without authorisation. If you are not an intended
recipient, please contact us at once by return email and then delete both
messages. We do not accept liability in connection with computer virus,
data corruption, delay, interruption, unauthorised access or unauthorised
amendment. This notice should not be removed"

From: [email-masked] (Michael Welzl)
Date: Sat Jul 28 04:27:34 2012
Subject: [Iccrg] About the state of MulTFRC
Message-ID: <[email-masked]>

Hi,

It's ages since the last time I posted something about MulTFRC ( http://heim.ifi.uio.no/~michawe/research/projects/multfrc/index.html 
  ) here.

So I thought I'd send this message, to tell you all that we're still  
on the case. The situation is - we got reviews, addressed all  
comments, EXCEPT for the request to come up with a good fixed point  
version of our algorithm. Note that the current draft can be  
implemented and used whenever floats are available (normally in user- 
space).

Developing a fixed point version has turned out to be  
muuuuuuuuuuuuuuuuch harder than we thought. We're still working on it  
(right now I have a master student who is looking into this), but it  
just takes it time.

Cheers,
Michael

From: [email-masked] (Yuchung Cheng)
Date: Fri Jul 20 22:41:53 2012
Subject: [Iccrg] Re: [tcpm] Review of draft-fairhurst-tcpm-newcwv-03
In-Reply-To: <[email-masked]>
References: <CAK6E8=[email-masked]> <[email-masked]> <[email-masked]> <CAK6E8=[email-masked]> <[email-masked]> <CAK6E8=ccre=[email-masked]> <[email-masked]>
Message-ID: <CAK6E8=[email-masked]>

On Fri, Jul 20, 2012 at 8:25 AM, Joe Touch <[email-masked]> wrote:
>
>
> On 7/20/2012 7:37 AM, Yuchung Cheng wrote:
> ...
>
>>> The server receives the request, and then sends a response. The server
>>> has a
>>> response that's typically larger - thus the burst. The server decides
>>> "how
>>> long has it been since I *received* anything? Since that time is very
>>> short,
>>
>>
>> but RFC 2861 does not use the most recently received timing? not in their
>> main algorithm (section 3.2) at least.
>
>
> I'm referring to the algorithm  as per Standard TCP [RFC5681] which, resets
> CWND to the restart window after the app goes idle (as described in this
> doc). However, RFC  2681 failed to note that the restart algorithm was
> widely deployed at the time, and was based on erroneous logic in a footnote
> of an unpublished extension of Van Jacobson's 1988 congestion control paper
> (ax explained in detail in draft-hughes-restart-00.txt).
>
>
>>> there's no slow-start restart, and the burst goes out.
>>>
>>> The only time the server would timeout and do slowstart restart would be
>>> if
>>> it decides to send something a while after anything has been received -
>>> that
>>> might occur for auto-refresh pages, but not much else.
>>>
>>> The issue is explained in detail here: J. Heidemann, K. Obraczka, J.
>>> Touch,
>>> ?Modeling the Performance of HTTP Over Several Transport Protocols,?
>>> IEEE/ACM Transactions on Networking, V5, N5, Oct. 1997, pp.616-630.
>>
>>
>> But why does receiving something recently justify the sending cwnd is safe
>> to
>>   not cause burst-induced losses? Sorry but I can't find the explanation
>> in
>> the paper.
>
>
> It doesn't justify it - it was an incorrect conclusion. The goal is "restart
> if you haven't SENT in a while", but Van's footnote said that most
> implementations at that time had a 'time since last received' timer, but not
> a 'time since last sent', and that because TCP is symmetric you can use the
> receive timer instead of the send one. That logic was false, and persistent
> HTTP turned out to have exactly that pattern.
>
> However, the mechanism proposed in this doc still allows most HTTP exchanges
> to burst an entire window - because it would be very likely that users will
> click on URLs within a received page within the 5 minute timeout.
>
> I.e., I don't think section 4 of this doc is appropriate (it still amounts
> to a send timer), and still favor the "burst-or-lose" style approach as
> recommended in draft-hughes-restart-00.txt.
I enjoy reading this draft. Very nice summary of all the mechanisms proposed!
I also like burst-or-lose due to its simplicity (and is interested in
rate-pacing as well).

In burst-or-lose, do the acks of the N packets increment the cwnd if
FlightSize < cwnd?

I'd recommend newcwv draft to cite and discuss hugest-restart draft.
>
> Joe
>
>
>

From: [email-masked] (Michael Welzl)
Date: Fri Jul 20 22:32:15 2012
Subject: [Iccrg] We still have a rather empty agenda...
Message-ID: <[email-masked]>

... and the cut-off date is Monday 23rd. So, if there's something  
you'd like to present in Vancouver, shoot!

Cheers,
Michael

From: [email-masked] (Yuchung Cheng)
Date: Fri Jul 20 15:44:09 2012
Subject: [Iccrg] Re: [tcpm] Review of draft-fairhurst-tcpm-newcwv-03
In-Reply-To: <[email-masked]>
References: <CAK6E8=[email-masked]> <[email-masked]> <[email-masked]> <CAK6E8=[email-masked]> <[email-masked]>
Message-ID: <CAK6E8=ccre=[email-masked]>

On Thu, Jul 19, 2012 at 10:37 AM, Joe Touch <[email-masked]> wrote:
>
>
> On 7/19/2012 10:26 AM, Yuchung Cheng wrote:
>>
>> On Thu, Jul 19, 2012 at 8:05 AM, Joe Touch <[email-masked]> wrote:
>>>
>>>
>>>
>>> On 7/16/2012 4:10 PM, Joe Touch wrote:
>>>>
>>>>
>>>>
>>>>
>>>> On 7/16/2012 3:56 PM, Yuchung Cheng wrote:
>>>>>
>>>>>
>>>>> Summary:
>>>>>
>>>>> First of all the problem this draft is trying to solve is important:
>>>>> AFAIK servers and data-centers disable slow-start after idle because
>>>>> it simply hurts latency too badly.
>>>>
>>>>
>>>>
>>>> If they're mostly doing HTTP, it shouldn't matter at all. HTTP's
>>>> transaction pattern defeats slow-start after idle anyway.
>
>>
>>
>> Why not if the interval between two HTTP responses are large, say two
>> minutes?
>> Your draft below suggested receiving HTTP requests have some effects but
>> I didn't see that in RFC 2861 (and I couldn't find the mailing list
>> discussion
>> cited either).
>
>
> Let's say the connection goes idle for 2 minutes. TCP doesn't do anything
> when a connection goes idle; it only does things when something is sent (in
> general).
>
> The most likely reason the server would have something new to send is that
> the client sends a new request. The client request is short enough to fit in
> 1-2 segments, so shouldn't be an issue (and Nagle should be off, since it's
> interactive with multibyte exchanges).
>
> The server receives the request, and then sends a response. The server has a
> response that's typically larger - thus the burst. The server decides "how
> long has it been since I *received* anything? Since that time is very short,

but RFC 2861 does not use the most recently received timing? not in their
main algorithm (section 3.2) at least.

> there's no slow-start restart, and the burst goes out.
>
> The only time the server would timeout and do slowstart restart would be if
> it decides to send something a while after anything has been received - that
> might occur for auto-refresh pages, but not much else.
>
> The issue is explained in detail here: J. Heidemann, K. Obraczka, J. Touch,
> ?Modeling the Performance of HTTP Over Several Transport Protocols,?
> IEEE/ACM Transactions on Networking, V5, N5, Oct. 1997, pp.616-630.

But why does receiving something recently justify the sending cwnd is safe to
 not cause burst-induced losses? Sorry but I can't find the explanation in
the paper.

>
> Joe

From: [email-masked] (Yuchung Cheng)
Date: Thu Jul 19 18:25:27 2012
Subject: [Iccrg] Re: [tcpm] Review of draft-fairhurst-tcpm-newcwv-03
In-Reply-To: <[email-masked]>
References: <CAK6E8=[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <CAK6E8=[email-masked]>

On Thu, Jul 19, 2012 at 8:05 AM, Joe Touch <[email-masked]> wrote:
>
>
> On 7/16/2012 4:10 PM, Joe Touch wrote:
>>
>>
>>
>> On 7/16/2012 3:56 PM, Yuchung Cheng wrote:
>>>
>>> Summary:
>>>
>>> First of all the problem this draft is trying to solve is important:
>>> AFAIK servers and data-centers disable slow-start after idle because
>>> it simply hurts latency too badly.
>>
>>
>> If they're mostly doing HTTP, it shouldn't matter at all. HTTP's
>> transaction pattern defeats slow-start after idle anyway.
Why not if the interval between two HTTP responses are large, say two minutes?
Your draft below suggested receiving HTTP requests have some effects but
I didn't see that in RFC 2861 (and I couldn't find the mailing list discussion
cited either).

Could you provide an example? Thanks.

>>
>> Joe
>
>
> PS - we did try to deal with this issue a decade ago, but the effort was not
> take up by the WG:
>
> http://www.isi.edu/touch/pubs/draft-hughes-restart-00.txt
>
> Joe
>

From: [email-masked] (Thomas Dreibholz)
Date: Thu Jul 19 11:15:19 2012
Subject: [Iccrg] Call for Papers of the PAMS 2013
Message-ID: <2777876.FjO5BTpWsQ@lupo>

We apologize if you receive multiple copies of this CFP.

CALL FOR PAPERS

The 3rd International Workshop on Protocols and Applications with Multi-Homing 
Support (PAMS 2013)
In conjunction with the 27th IEEE International Conference on Advanced 
Information Networkingand Applications (AINA 2013)
Barcelona, Spain, March 25-28, 2013
http://simula.no/pams2013

The intent of our workshop is to bring together people from research and
industry, in order to provide a discussion forum for state-of-the-art topics
related to multi-homing on Network, Transport, Session and Application Layers.
The PAMS workshop will include full-paper sessions as well as a poster session
(with short presentations) to introduce preliminary ideas as well as work in
progress.

Workshops proceedings will be published by the IEEE CS Conference Publishing
Service and will be included in the Digital Library.

The main topics to be addressed include (but are not limited to):

    * Network Resilience by Multi-Homing
    * Network Architectures for Multi-Homed Systems
    * Performance Evaluation of Multi-Homed Systems
    * Deployment of Multi-Homed Protocols in Existing Networks
      with Middleboxes
    * Design and Implementation of Multi-Homed Systems
    * Testbeds for Multi-Homed Systems
    * Load Sharing and Load Balancing for Multi-Homed Systems
    * Mobility for Multi-Homed Systems
    * Protocols with Multi-Homing Support
    * Congestion and Flow Control of Multi-Homed Systems
    * Quality of Service for Multi-Homed Systems
    * Multi-Homing for Interconnection Networks
    * Security of Multi-Homed Systems
    * Application Deployment and Support for Legacy Applications
    * Cross-Layer Optimisation for Multi-Homed Systems
    * Multi-Homing in the Context of the Future Internet

GENERAL CHAIRS:

    * Thomas Dreibholz, Simula Research Laboratory, Norway
    * Hakim Adhari, University of Duisburg-Essen, Germany

PROGRAM CHAIRS:

    * Martin Becke, University of Duisburg-Essen, Germany
    * Thomas Dreibholz, Simula Research Laboratory, Norway

PUBLICITY CHAIRS:

    * Glenford Mapp, Middlesex University, United Kingdom
    * Xing Zhou, Hainan University, China

PROGRAM COMMITTEE

    * Hakim Adhari, University of Duisburg-Essen, Germany
    * Nicola Altan, ista International, Germany
    * Paul Amer, University of Delaware, U.S.A.
    * Holger Bleul, DB Systel, Germany
    * Anna Brunstr?m, Karlstad University, Sweden
    * Ahmed Elmokashfi, Simula Research Laboratory, Norway
    * Kristian Evensen, Simula Research Laboratory, Norway
    * Ernst Gunnar Gran, Simula Research Laboratory, Norway
    * Seok Joo Koh, Kyungpook National University, South Korea
    * Amund Kvalbein, Simula Research Laboratory, Norway
    * Glenford Mapp, Middlesex University, United Kingdom
    * Preethi Natarajan, Cisco, U.S.A.
    * Brad Penoff, Google, U.S.A.
    * Esbold Unurkhaan, Mongolian University of Science and Technology, 
Mongolia
    * Andreas Timm-Giel, TU Hamburg-Harburg, Germany
    * Alan Wagner, University of British Columbia, Canada
    * Michael Welzl, University of Oslo, Norway
    * Xing Zhou, Hainan University, China

IMPORTANT DATES

    * Paper Submission Deadline:       October 01, 2012
    * Author Notification:             December 01, 2012
    * Camera-Ready Paper Submission:   January 06, 2013

CONTACT

For further information, please contact:

    * Thomas Dreibholz ([email-masked])
    * Hakim Adhari ([email-masked])

WEBSITE

http://simula.no/pams2013

From: [email-masked] (Mirja Kuehlewind)
Date: Thu Jul 19 11:00:47 2012
Subject: [Iccrg] Re: [tcpm] Review draft-fairhurst-tcpm-newcwv-03
In-Reply-To: <[email-masked]>
References: <CAK6E8=[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Gorry,

here as promised the more detailed comments:

- section 4: Please add a reference to the later chapter that the value of 5 
minutes will be further discussed.

- section 4.2: Please explain where the 2/3*cwnd comes from. I would have 
though validated phase is when flightsize >= cwnd or maybe >= cwnd - 
maxburstsize (as in today's implementation the cwnd will be limited to 
flightsize+maxburstsize anyway)

- section 4.3: Should the case that the 5 minutes are over here be mentioned 
as well...?

- section 4.3: in 2. bulletpoint the reference is wrong; should be to section 
4.3.2.

- section 4.3: I would merge the last paragraph into there first bulletpoint 
as I was asking me exactly that question when reading the first bulletpoint

- section 4.3.1: "by setting a burst size limit, using a pacing algorithm, or 
some other method." -> I think there should be one (or more) mechanisms 
specified here as part of the algorithm

- section 4.3.1: "cwnd = max(FlightSize*2, IW)" -> Why flightsize*2? This can 
still be a very large not validated window. I would go for 
flightsize+maxburstsize (at least have static offset here). 

- section 4.3.1: "cwnd = max(FlightSize*2, IW)" -> If you keep this, it should 
be  "cwnd = min(max(FlightSize*2, IW),cwnd)"

- section 4.3.1: "ssthresh = max(ssthresh, 3*cwnd/4)" -> Is this the new or 
the old cwnd? Why are you taking a different value than usually?

- section 4.3.2: Why is the reaction to congestion different than what should 
be done when leaving the nonvalidated phase?

- section 4.3.2: "cwnd = ((FlightSize - R)/2)" -> I wouldn't wanne specify the 
concrete congestion response in this document. There might be congestion 
control algorithms like DCTCP that so something different than halving (at 
least for ECN). The document should just say something like "perform the 
normal congestion response specified by the used congestion control algorithm 
after the adaption of the congestion window". You might even think about 
having two window variables here. Will the congestion control only controls 
the cwnd, your second window, which than determines the allowed packets in 
flight, might be larger. Moreover, you have to make sure that the congestion 
control will not raise the cwnd anyfurther while being application-limited!

- section 4.4: I would make this an own section 5

- section 4.4: Are there references available on what the "idle intervals of 
common applications" and "period for which the capacity of an Internet path 
may commonly be regarded as stable" are?

- section 4.4: 3. paragraph: Maybe be even more strict and say something 
like "If rapid changes in the path characteristics are detected, the new 
method SHOULD not be used anymore". Maybe even require to monitor the RTT's 
and give a threshold when to disable this method.

- section 4.4: Also refer the respective TCP mechanisms that use a 5 minutes 
timer.

Mirja

On Wednesday 18 July 2012 19:55:14 Mirja K?hlewind wrote:
> Hi Gorry,
>
> I believe this draft addresses a very important problem which exists and
> need to be solved. But I'm not too sure about the solution that is
> proposed. But I also don't know what the right/perfect solution would be.
>
> My biggest concern is regarding potential bursts you might introduce. Maybe
> I'm too conservative but I believe whatever you gone chance in TCP, one
> thing to avoid is the chance to cause large bursts of packets. Recently, it
> was actually recognized that the block sending behavior of youTube
> (eventough it is using normal standard-conform TCP) leads to bursts and
> large loss probabilities. Actually that is a problem that exists in today's
> TCP and needs to be addressed too.
>
> So I guess what I propose is to limit the burst size. This is not
> completely though through yet but you could allow some slow start like
> behavior in CA if the flow has been application limited. So maybe your
> mechanism could be extended to allow only bursts of 2 (or 3) packets. That
> would mean that you would be able to increase your sending rate form
> 1*flightsize to 2*(or 3*)flightsize in one RTT if the flow was application
> limited before. Don't you think that might be already sufficient?
> In case of idle times this would (unfortunately) lead back to normal slow
> start behavior but the IW10 draft also specifies a restart window of 10.
> This might help the problem already a lot...?
> Btw. in Linux (and potentially in some RFC?) there is already a maximum
> burst size of 3 implemented but this is only used to limited the congestion
> window to flightsize + maxburstsize.
>
> I will send some more detailed comments on the draft tomorrow (don't have
> my notes with me at the moment). But one more point are the values you have
> chosen for the several thresholds. I know there is a whole section
> reasoning why 5 minutes have been chosen but that didn't really convince
> me. One more though on my proposal above (which is still not though
> through): If you would track the max cwnd since the last congestion
> notification event and use this as a threshold upto which the kind of
> slow-start-behavior in CA (as explained above) is allow, I don't think that
> there is any time limit needed at all...
>
> I guess this whole idea leads to something similar as proposed by TCP
> Laminar. As Yuchung mentioned those two proposals should be regarded
> together.
>
> Some more detailed comments tomorrow...
>
> Mirja
>
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

-- 
-------------------------------------------------------------------
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: [email-masked] (Mirja =?iso-8859-1?q?K=FChlewind?=)
Date: Wed Jul 18 18:53:57 2012
Subject: [Iccrg] Review draft-fairhurst-tcpm-newcwv-03
In-Reply-To: <CAK6E8=[email-masked]>
References: <CAK6E8=[email-masked]>
Message-ID: <[email-masked]>

Hi Gorry,

I believe this draft addresses a very important problem which exists and need 
to be solved. But I'm not too sure about the solution that is proposed. But I 
also don't know what the right/perfect solution would be.

My biggest concern is regarding potential bursts you might introduce. Maybe 
I'm too conservative but I believe whatever you gone chance in TCP, one thing 
to avoid is the chance to cause large bursts of packets. Recently, it was 
actually recognized that the block sending behavior of youTube (eventough it 
is using normal standard-conform TCP) leads to bursts and large loss 
probabilities. Actually that is a problem that exists in today's TCP and 
needs to be addressed too.

So I guess what I propose is to limit the burst size. This is not completely 
though through yet but you could allow some slow start like behavior in CA if 
the flow has been application limited. So maybe your mechanism could be 
extended to allow only bursts of 2 (or 3) packets. That would mean that you 
would be able to increase your sending rate form 1*flightsize to 2*(or 
3*)flightsize in one RTT if the flow was application limited before. Don't 
you think that might be already sufficient? 
In case of idle times this would (unfortunately) lead back to normal slow 
start behavior but the IW10 draft also specifies a restart window of 10. This 
might help the problem already a lot...?
Btw. in Linux (and potentially in some RFC?) there is already a maximum burst 
size of 3 implemented but this is only used to limited the congestion window 
to flightsize + maxburstsize.

I will send some more detailed comments on the draft tomorrow (don't have my 
notes with me at the moment). But one more point are the values you have 
chosen for the several thresholds. I know there is a whole section reasoning 
why 5 minutes have been chosen but that didn't really convince me. 
One more though on my proposal above (which is still not though through): If 
you would track the max cwnd since the last congestion notification event and 
use this as a threshold upto which the kind of slow-start-behavior in CA (as 
explained above) is allow, I don't think that there is any time limit needed 
at all...

I guess this whole idea leads to something similar as proposed by TCP Laminar. 
As Yuchung mentioned those two proposals should be regarded together.

Some more detailed comments tomorrow...

Mirja

From: [email-masked] (John Leslie)
Date: Wed Jul 18 16:41:18 2012
Subject: [Iccrg] Re: ECN marking over wireless networks
In-Reply-To: <25858_1342606[email-masked]>
References: <AFC377AFCC0FBD4DABE49F4B81EC4F1A0377A415@ftrdmel1> <[email-masked]> <[email-masked]> <25858_1342606[email-masked]>
Message-ID: <20120718154202.GD76033@verdi>

sebastien.jobert <[email-masked]> wrote:
> 
> The question that is raised here, I believe, is to understand how ECN
> marking over the radio segment can help (if it helps...) when combined
> with existing/already implemented radio resources sharing algorithm
> (e.g. PF). And how this signal might interact with other mechanisms
> (TCP, incentives, ...) to improve the situation in case of radio
> congestion compared to the case where ECN marking is not used.

   First principle: ECN _can_ signal congestion faster than a packet
loss can be inferred by the sender. This is an unmitigated good-thing.

> At the end, I agree that it might not be the most optimal solution
> (but I'll tend to think that wireless systems always require some
> kind of compromise - you might optimize one particular parameter at
> the expense of another).

   Agreed: ECN can't signal congestion to the sender as fast as a
backpressure signal from the wireless access point. But we do have a
standard for ECN, whereas ICMP source-quench has been thoroughly
deprecated.

> I also agree with Jim that fairness should refer to "transmission
> opportunities" in this type of wireless systems rather than bandwidth.

   I agree as well: transmission opportunities tend to be the limiting
factor. (This is not pure packet-counting, but is poorly correlated
with packet size.)

>... What you mentioned about bugs on different drivers makes me think
> that some sort of documentation about expected behavior for ECN
> marking would be useful.

   Not sure what we can say...

> Thanks also for the information about CoDel AQM (that I did not know
> before) to be considered instead of RED. We'll investigate this.

   CoDel fundamentally says to discard packets based on time-in-queue
(and doesn't yet refer to ECN-marking). I see great promise for CoDel
ECN-marking instead of drop, but so far I know of no specification for
this. Specifying such a thing seems very worthwhile: I don't know the
best route for doing so...

>... Note that this heterogeneity problem is quite common in practice,
> and applies also to other technologies (the various behaviors of
> forwarding engines of IP routers is a very good example), but it
> fortunately did not preclude developing in the past generic models
> for the purpose of progressing a common understanding of certain
> mechanisms.

   +1

> I still really can see benefits in trying to document such ECN marking
> algorithms over wireless networks, even if in practice, a real
> implementation might differ from those general descriptions.

   In practice, implementations are likely to be all-over-the-place.

   In particular, we should expect ECN marking to follow AQM with
sub-optimal parameters. Observing the problems is definitely ICCRG work.
I dare to hope that ECN marking following CoDel could be standardized
sufficiently to become a comfortable choice.

> One reason justifying this: ECN marking over wireless network is
> mentioned in different documents (e.g. 3GPP TS 36.300, 26.114,
> draft "Mobile Communication Congestion Exposure Scenario" in Conex WG,
> ...), how would you use it in practice if you have no idea about what
> is done by the equipment?

   There is certainly a problem perceived here; but I'm not sure there's
a real problem. So long as the ECN marking applies equally to flows,
those flows can apply equivalent throttling of send rate, and we'll be
better off than without ECN.

   OTOH, actual optimization _will_ work better if the sender doesn't
have to guess what the ECN marks actually reflect...

> That being said, I fully agree that no general recommendation can be
> done at this stage, but I would also really encourage people to work
> on this so that some sort of general recommendations could be developed
> in the future.

   I wouldn't agree that "no" general recommendation is appropriate, but
certainly any recommendation must be "tentative" at this point.

> I also agree that Conex approach might help on the fairness item, with
> some adaptations.

   That discussion probably belongs on the ConEx list...

--
John Leslie <[email-masked]>

From: [email-masked] (sebastien.jobert)
Date: Wed Jul 18 11:07:40 2012
Subject: [Iccrg] Re: [conex] ECN marking over wireless networks
In-Reply-To: <[email-masked]>
References: <AFC377AFCC0FBD4DABE49F4B81EC4F1A0377A415@ftrdmel1> <[email-masked]> <[email-masked]>
Message-ID: <25858_1342606[email-masked]>

Hi,

Thank you very much for your feedbacks on this item, and sorry for the very long delay to reply.
I won't be in Vancouver unfortunately to discuss this with you, but will consider attending the next meetings.

Please find below some additional thoughts about this thread.

1) Fairness

You suggest Michael to take into account the application requirements in addition to a more basic sharing of the resources. Taking a local decision has also been suggested (I assume that "local" means here: "by the Access Point", which is normally what is done for ECN marking - the decision is always local). It should be noted that taking into account the application requirements would then imply that the Access Point has the knowledge about which types of applications are running over all the terminals... which might be quite difficult in practice, and possibly not desirable in some cases.

The question that is raised here, I believe, is to understand how ECN marking over the radio segment can help (if it helps...) when combined with existing/already implemented radio resources sharing algorithm (e.g. PF). And how this signal might interact with other mechanisms (TCP, incentives, ...) to improve the situation in case of radio congestion compared to the case where ECN marking is not used. At the end, I agree that it might not be the most optimal solution (but I'll tend to think that wireless systems always require some kind of compromise - you might optimize one particular parameter at the expense of another).

I also agree with Jim that fairness should refer to "transmission opportunities" in this type of wireless systems rather than bandwidth. Thanks also Jim for the details on the Linux drivers, this is quite useful (it seems then that in these implementations, a mix between the two models that I briefly depicted is considered). What you mentioned about bugs on different drivers makes me think that some sort of documentation about expected behavior for ECN marking would be useful. Thanks also for the information about CoDel AQM (that I did not know before) to be considered instead of RED. We'll investigate this.

2) Heterogeneity

Of course, radio systems and drivers may have different behaviors. However, there are some common aspects to all these systems, e.g. the radio transmission channel has some common properties. I assume that a generic model (or a few generic models) might be developed (Proportional Fair is for instance a quite common algorithm).

Note that this heterogeneity problem is quite common in practice, and applies also to other technologies (the various behaviors of forwarding engines of IP routers is a very good example), but it fortunately did not preclude developing in the past generic models for the purpose of progressing a common understanding of certain mechanisms.

I still really can see benefits in trying to document such ECN marking algorithms over wireless networks, even if in practice, a real implementation might differ from those general descriptions. One reason justifying this: ECN marking over wireless network is mentioned in different documents (e.g. 3GPP TS 36.300, 26.114, draft "Mobile Communication Congestion Exposure Scenario" in Conex WG, ...), how would you use it in practice if you have no idea about what is done by the equipment?

That being said, I fully agree that no general recommendation can be done at this stage, but I would also really encourage people to work on this so that some sort of general recommendations could be developed in the future. I also agree that Conex approach might help on the fairness item, with some adaptations.

Cheers,

S?bastien

-----Message d'origine-----
De?: [email-masked] [mailto:[email-masked]] De la part de Mirja Kuehlewind
Envoy??: dimanche 10 juin 2012 23:46
??: [email-masked]
Cc?: [email-masked]
Objet?: [Iccrg] Re: [conex] ECN marking over wireless networks

Hi Micheal,
 
just two quick comment on your two points:
>
> 1) Fairness. If I get to send at a lower rate, I waste more of
> everyone's resources. My own benefit is also reduced. Should I send even
> less than what the system now allows me, to be friendly to everyone, or
> should I send as much as I can? I might be in worse conditions than
> others; does that mean that I should be even worse off? I think the
> correct answer would have to be a function of the impact that my own
> traffic has on the utility that everyone else is getting out of the
> network resources, and the utility that I am getting out of them. We can
> assume a general case of a strictly concave function and solve the
> problem with calculations a la proportional fairness... but then again,
> not all applications have such utility functions (e.g. VoIP is
> different, and using e.g. VoIP over WiFi is not at all uncommon). A good
> solution would therefore have to make a local decision that is based on
> knowing which applications are used.
Yes, you should make the decision locally! But you need some information about 
the network state. ECN is only the signal protocol that provides you this 
information. ECN says you should react on this signal the same way as you 
would react to loss but that doesn't you have to halve your rate. ECN does 
not specify any action that will actually change your traffic; it's a signal 
protocol only.

>
> 2) Heterogeneity: wireless systems differ greatly. For instance, in [1]
> we found that, **in total absence of real noise**, TCP's throughput
> across a WLAN can very much depend on the chosen rate adaptation
> mechanisms. Essentially, this means that some rate adaptation mechanisms
> do a bad job at trying to detect noise, and mistake collisions for it.
> They then switch to a lower rate when they really shouldn't (on a side
> note, Minstrel, available in MadWifi, seemed to always work best). Now,
> note that in a practical WLAN you don't even know which rate adaptation
> mechanism is chosen by the individual hosts participating! Under such
> conditions, how would you make an ECN-marking rule work well for
> everyone? Yes we could design a rule, but that would have to depend on
> the driver and even the configuration of not only the AP but all the
> hosts currently involved.
I believe that's the point we are talking about. In general ECN/RED should 
work no matter what network you are looking at. The only question is, if we 
know something specific about the link, as we do know for a mobile networks, 
can we do something better (like adjusting the RED parameters). And for 
mobile network, I believe, this will be specific for each operator as they 
know their network best.

Mirja

>
> To conclude: yes I think this is interesting stuff, and worth
> investigating as a research topic. As such it's perfectly fine to
> discuss it at ICCRG (I suggest: on the basis of measurements). And maybe
> (an adaptation of) conex can solve problem #1 above - but not problem
> #2. It is therefore clear to me that we cannot make a general
> recommendation at this stage, and I think it's very likely that, even
> after carrying out a lot of research on this, no *general*
> recommendation can ever be made.
>
> Cheers,
> Michael
>
> [1] Naeem Khademi, Michael Welzl, Stein Gjessing: "Experimental
> Evaluation of TCP Performance in Multi-rate 802.11 WLANs", accepted for
> publication, IEEE WoWMoM 2012, 25-28 June 2012, San Francisco,
> California, USA.
>
> On 5/9/12 10:48 PM, [email-masked] wrote:
> > Hi,
> >
> > There has been some discussion during the IETF 83 in Paris in ICCRG
> > and CONEX WG about relevant ECN marking algorithms over wireless
> > networks.
> >
> > Some aspects related to this topic are discussed in this draft:
> > http://www.ietf.org/id/draft-jobert-tsvwg-pre-congest-notif-mobile-00.pdf
> >, briefly introduced during ICCRG meeting.
> >
> > This email aims at starting some discussion on the mailing lists of
> > ICCRG and CONEX, as requested by the chairs after the discussions
> > during IETF 83.
> >
> > Essentially, the main aspect pointed out during the discussions was
> > that there might benefits in taking into account the radio conditions
> > of the mobile terminal for ECN marking over the radio segment and for
> > congestion-volume counting. The reason for this is that it requires
> > more radio resources to transmit the same amount of data to a terminal
> > in bad radio conditions compared to a terminal in good radio conditions.
> >
> > As an introduction to the discussion, it might be useful to mention
> > that different potential /use cases/ for ECN marking involving the
> > mobile terminal could be envisaged:
> >
> > 1.interaction with TCP
> >
> > 2.adapt the coding rate of adaptive application (e.g. adaptive
> > streaming, etc.), as suggested in 3GPP TS 36.300 document
> >
> > 3.stop/delay the non-urgent applications (background tasks in the
> > terminal, etc.)
> >
> > 4.congestion-volume counting (as for Conex related use cases)
> >
> > This list is obviously non-exhaustive, and shows that depending on the
> > final utilization of the congestion notification, different algorithms
> > for ECN marking over the radio segment might be imagined. The most
> > optimal algorithm certainly depends on the final objective.
> >
> > From the comments received during the discussion, it seems that the
> > first ECN marking algorithm over the radio segment that comes to most
> > people's mind is to consider an average queue length exceeding a given
> > threshold, as for RED. It should be noted that because the radio
> > segment shares the radio resource among several terminals, one
> > dedicated queue per terminal is in general considered.
> >
> > Therefore, if one would like to apply RED over a wireless segment, it
> > should be clarified whether it would be applied independently on each
> > dedicated queue per terminal (n instances of RED considered for the
> > radio segment), or on the sum of all the dedicated queues (1 single
> > instance of RED considered for the radio segment). This would lead to
> > two different ECN marking /criteria/:
> >
> > 1.RED based on the individual queue of each terminal
> >
> > 2.RED based on a single shared queue between all the terminals
> >
> > Several remarks were raised during the presentation of the draft in
> > ICCRG and the discussion in CONEX:
> >
> > -On the interactions with TCP (use case #1 listed above), it was
> > mentioned that TCP works on a longer timescale relative to the
> > wireless channel. In other words: the radio conditions may vary more
> > quickly than TCP reactions. This is correct, however, it should be
> > mentioned that the objective of ECN marking over the radio segment is
> > not to replace the existing radio schedulers, which already provide a
> > suitable control loop over these shorter time scales. As an example,
> > the very common Proportional Fair (PF) algorithm aims at addressing
> > exactly this point, by trying to optimize the allocation of radio
> > resources (the terminals in good instantaneous radio conditions are
> > favored compared to the others, as to optimize the cell capacity,
> > while certain fairness is ensured in the longer term by taking into
> > account also the averaged throughputs delivered to the terminals).
> >
> > -Still regarding the interactions with TCP (use case #1 listed above),
> > assume now that a PF algorithm is used to control the allocation of
> > radio resources. It was mentioned also that if it is assumed that ECN
> > marking is done according to the individual queue of each terminal
> > (criteria #1 listed above), then a terminal in bad radio conditions
> > will already experience ECN marking more often without the need to
> > weight the probability of the ECN marking with the radio conditions of
> > the terminal. This is due to the fact that PF provides higher
> > throughput to terminals in good averaged radio conditions than in bad
> > averaged radio conditions. Actually, the amount of ECN marking will
> > depend in this case whether the throughput required to transmit the
> > data to a particular terminal is lower than the throughput provided to
> > this terminal by PF; if not, then no ECN marking should happen for
> > this terminal in these conditions (even during congested periods
> > actually).
> >
> > -Based on this discussion, it seems to me that the interaction of ECN
> > marking with TCP should not be analyzed in terms of benefits it brings
> > to control the allocation of resources over the radio segment, which
> > is already under the control of the radio scheduler. It seems that
> > this second control loop provided by ECN marking interacting with TCP
> > would rather aim at indicating when the traffic rate of a terminal
> > exceeds the throughput provided by PF to this terminal, which could be
> > useful for use case #2 (coding rate adaptation). Basically, it is
> > expected that this second control loop would try to "align" with the
> > throughput provided by the first one (keeping in mind that PF provides
> > throughputs varying with time).
> >
> > -The same example but now with the ECN marking criteria #2 instead of
> > #1 raises however issues. Indeed, in case the throughput required to
> > transmit the data to one particular terminal is lower than the
> > throughput provided to this terminal, this will lead to ECN marking
> > for all the terminals, even the ones below the PF throughput, which is
> > a situation that should be avoided when interaction with TCP is
> > desirable. Excessive traffic consumption on one terminal should not
> > impact the others (i.e. should not lead to the generation of ECN
> > marking for the others). Definitely, the criteria #1 does not seem a
> > good idea when interaction with TCP is desired.
> >
> > -Considering the use case #3 depicted earlier now, it should be noted
> > however that the previous situation with PF + ECN marking based on
> > individual queues (criteria #1) has some limitation. Indeed, in case
> > of radio congestion (assume here that radio congestion means that all
> > the radio resources are used and are not enough to transmit all the
> > data to be transmitted to all the terminals - a more accurate
> > definition might be found), some of the terminals may not received ECN
> > marking, as indicated before (in case they require less than what PF
> > can provide to them). Perhaps some of the data transmitted to these
> > non-notified terminals are not so critical and might be delayed, as to
> > free resources to the other users with more important traffic to be
> > exchanged. The depicted situation does not provide incentives to do
> > this, because ECN marking only applies to some users. It is the reason
> > why it might be interesting to consider other ECN marking algorithms
> > (which might not aim at interacting necessarily with TCP; BTW not all
> > the applications are running over TCP), as to inform about the
> > congestion situation. The idea is to say to the end user: "Hey! The
> > system starts being full, the PF algorithm will still provide you with
> > some network resources, but if some of your data can be delayed,
> > please do so!" Of course, this kind of approach might be coupled with
> > congestion-volume counting / CONEX use cases, to provide incentives.
> >
> > -Let's take a practical example to illustrate (note sure it is the
> > best one, but it is the one that comes to my mind.): you need to go to
> > some administration to collect some administrative document - say, a
> > voting card to elect your new president. There is already a long
> > queue, but you could pass with a "certain priority" because what you
> > need to do is faster than what other people have to do. However, if
> > you collect your document, you consume resources of the system that
> > will not be available to the others during this time - the person in
> > front of you will be busy giving you your document. And what you need
> > to do is not urgent - the election is not tomorrow, you will have time
> > to come back later. Perhaps you would like to be fair with the other
> > people having more urgent things to do and waiting in the queue, and
> > you will not wait and instead come back later? And perhaps a signal
> > indicating the congestion might be useful (it is probably good to know
> > if the queue is long or not, rather than waiting without information).
> >
> > -Considering the use case #4 depicted earlier now on congestion-volume
> > counting: it seems logical to me that the count would take into
> > account the real network resource usage rather than simply the number
> > of bits transmitted. This would provide again incentives to users in
> > bad radio conditions to delay non-urgent network usage. Moreover, an
> > interesting question which should be raised would be to define what
> > corresponds to a "congested period" for the radio segment: is it only
> > when the terminal exceeds its PF rate, or should a congestion period
> > be considered when the system starts being full/is full? This might
> > trigger different ECN marking algorithms on the wireless segment.
> >
> > I had noted two other comments from the discussions in IETF 83:
> >
> > -TCP middlebox accelerating TCP window growth: some comment was made
> > on the mic, however I am not sure that I understood what this device
> > is supposed to do; would anyone of you have some reference on this?
> >
> > -Retransmission over the radio segment: should it be taken into
> > account as well for congestion-volume counting? It would mean that a
> > lost packet that is retransmitted by the low layers should be counted
> > twice? (after all, if it was retransmitted by TCP, it would have been
> > counted twice as well, right?)
> >
> > Feedback on this discussion is welcomed. Thanks in advance.
> >
> > Cheers,
> >
> > *S?bastien JOBERT*
> > Orange Expert "Future Networks", network synchronization and QoS in
> > mobile networks
> > *Orange Labs, Networks & Carriers - France Telecom R&D*
> > [email-masked] <mailto:[email-masked]>
> >
> >
> >
> > _______________________________________________
> > conex mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/conex
>
> _______________________________________________
> conex mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/conex

-- 
-------------------------------------------------------------------
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
-------------------------------------------------------------------

_______________________________________________
Iccrg mailing list
[email-masked]
http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

From: [email-masked] (Yuchung Cheng)
Date: Mon Jul 16 23:55:36 2012
Subject: [Iccrg] Review of draft-fairhurst-tcpm-newcwv-03
Message-ID: <CAK6E8=[email-masked]>

Summary:

First of all the problem this draft is trying to solve is important:
AFAIK servers and data-centers disable slow-start after idle because
it simply hurts latency too badly. Modern TCP-smart applications all
use persistent connections to amortize handshake and slow-start
overhead and the RFC2861 standard nullifies that to certain extent.
While the applications don't want to create big burst to cause
congestion, they have no better choices (low latency vs occasional
burst losses: choose one). This draft proposes a middle road. Thanks
for starting this!

Details:
Section 1
I found the term "variable-rate" application little awkward: for
example some constant-rate (CBR) app may still go through slow-start,
overshoots, and experiences non-validated phases. But it's nit.

Section 4.1
Since the draft already requires SACK, I recommend to use RFC3517 pipe
to better measure the amount of outstanding data in the network.

Section 4.2

a) Justification of 2/3 and 1/3 is much appreciated.
b) During the validated phase when FS >= 2/3cwnd, are ACKs used to
compute new cwnd. E.g., in slow-start with cwnd=30 and FS=20, will the
next 10 ACKs increase the cwnd to 40? also is this phase check applied
to both transmitting new data and receiving acks?

Section 4.3.1
"  An application that remains in the non-validated phase for a period
   greater than five minutes is required to adjust its congestion
   control state.  At the end of the non-validated phase, the sender
   MUST update cwnd:

           cwnd = max(FlightSize*2, IW)."
Some justification to set cwnd to double the FlightSize? it seems with
2/3 rule in the non-validated phase, cwnd can grow to as big as 4/3 of
original value at the end of the non-validated phase.

btw, it flows better if 4.3.1 and 4.3.2 are swapped.

Section 4.3.2
"A sender that detects a packet-drop or receives an ECN marked packet
 MUST calculate a safe cwnd, based on the volume of acknowledged data:

        cwnd = FlightSize - R.

 Where, R is the volume of data that was reported as unacknowledged by
 the SACK information.  This follows the method proposed for Jump
 Start [[Liu07]."
so is R 0 or 1 of of an ECN marked packet?

Some justification to your approach compared to RFC5861?
i.e. why (FlightSize - R)/2 vs FlightSize/2?

After thougths:
Since this RFC attempts to replace RFC2861, maybe it can also address
this performance handicap in the introduction of RFC2861?

"We propose that the TCP sender should not increase the congestion window
   when the TCP sender has been application-limited (and therefore has
   not fully used the current congestion window).  We have explored
   these algorithms both with simulations and with experiments from an
   implementation in FreeBSD."

This happens frequently today because many application pauses are
within RTOs. For example, the acks of smaller HTTP responses after
some big one will now not used to compute cwnd. They are used for RTO
estimation only.

I think we need a general solution to cover when cwnd > pipe. So far
we have laminar and your draft. But a unified solution would be great
but we are making progress :)

Thanks.

From: [email-masked] (Matt Mathis)
Date: Sat Jul  7 23:03:14 2012
Subject: [Iccrg] TCP Laminar patch posted
Message-ID: <CAH56bmAM47d7ET=[email-masked]>

I posted a "version 0.1" Laminar patch at
https://developers.google.com/speed/protocols/tcp-laminar . It is
still very much a work in progress, but all of the core functionality
is present and seems to be working.   There are still a number of
pieces missing: non-Reno, non-CUBIC congestion control, and cwnd
validation.

People who work on Linux might be interested in trying it, or at least
looking at the code.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

From: [email-masked] (Michael Welzl)
Date: Fri Jul  6 10:59:44 2012
Subject: [Iccrg] Empty space on the agenda, and still looking for reviewers for draft-fairhurst-tcpm-newcwv-03
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi,

As you can see at 
http://www.ietf.org/proceedings/84/agenda/agenda-84-iccrg there's plenty 
of space on our agenda, in case someone wants to present something...

On a side note, we're still looking for volunteers to review 
draft-fairhurst-tcpm-newcwv-03, see below.

Cheers,
Michael

On 6/22/12 9:28 AM, Michael Welzl wrote:
> Hi,
>
> First of all, the draft is here:
> http://tools.ietf.org/html/draft-fairhurst-tcpm-newcwv-03
>
> I think there were no public comments on the mailing list, just at the 
> meeting @ IETF 80. Here they are:
> http://www.ietf.org/proceedings/80/minutes/iccrg.txt
>
> As for the question "may we now return to TCPM": we don't take a 
> formal role in this process - i.e., you may decide to take this to 
> TCPM at any time.
>
> The point of ICCRG review is to get comments and incorporate feedback, 
> up to a point where, if someone in TCPM says "this and that looks like 
> open research, you should take this to ICCRG" you could ideally point 
> to reviews that were already done there, and comments that were 
> incorporated, thereby hopefully settling the discussion. If pointing 
> to reviews can't settle it, this is going to make the document bounce 
> back to ICCRG with a specific request from TCPM, which is also fine, 
> but I think it would be most efficient to minimize (or, even better, 
> altogether avoid) such iterations.
>
> Since Gorry is saying that they'd love more comments, can I ask for 
> volunteers to do a thorough review? For previous proposals of changes 
> to TCP's congestion control, we had 2-3 such reviews.
>
> Cheers,
> Michael
>
>
> On 6/21/12 4:43 PM, Gorry Fairhurst wrote:
>> ICCRG,
>>
>> We have revised our draft called "Updating TCP to support
>> Variable-Rate Traffic". We think the feedback we received after ICCRG
>> has been addressed and are grateful to all who commented. This new
>> version is also intended to be easier to read.
>>
>> Here is a summary of issues and NiTs that were corrected:
>> (1)    Non-validation phase time changed to 5 from 6 minutes,
>>     following comments that TCP aleady has a 5 minute timer.
>> (2)    Section 4.3.2:  At the end of the recovery phase, the TCP sender
>>     MUST reset the cwnd to (FlightSize-R)/2 and not FlightSize/2.
>> (3)     Various places to improve language and address questions about
>>     ambiguities after iccrg.
>> (4)     Note change of author (Israfil has now moved-on to a job
>>     elsewhere).
>>
>> We'd love more comments, and also like to know what happens next to
>> this draft. Are there more things that ICCRG wishes to think upon, or
>> may we now return to TCPM with a proposal to take this forward there?
>>
>> Best wishes,
>>
>> Gorry
>>
>>
>>
>>
>>
>>
>>
>
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg