Subject: [Iccrg] Meeting @ Atlanta IETF
From: [email-masked] (Michael Welzl)
Date: Thu Aug 30 07:38:48 2012

Hi,

We're planning on having an ICCRG session at the upcoming IETF in Atlanta, and we need to request a slot soon. To make sure that we request the right slot size, it would be great to already have an indication of the number of speakers and length of talks...  so, if you're planning on presenting something, please let us know - with (tentative, you can still update it later) title, and expected (desired) duration.

Thanks!
Michael

From: [email-masked] (Mirja Kuehlewind)
Date: Tue Aug  7 21:40:07 2012
Subject: [Iccrg] Re: Review draft-fairhurst-tcpm-newcwv-03 - response
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Gorry,

two responses and a comment; the comment first: Did you post the existence of 
your draft on the rtcweb-cc list? This should be intersting for these guys as 
well.

1) cwnd = min(max(FlightSize*2, IW),cwnd)
I'd say this is needed to cover the case where 2*Flightsize > cwnd

2) halving the window on loss/congestion
Your draft should only address how to adapt the congestion window when 
application-limited. It should not preclaim what kind of congestion control 
is done otherwise. Halving the window on loss is part of the congestion 
control algorithm itself. You can say that in case of loss/congestion the 
cwnd should be reset to Flightsize-R and then the normal congestion response 
should be applied. In case of RFC5681 this means halving. Does this make 
sense to you?

Mirja

On Monday 06 August 2012 20:42:42 Gorry Fairhurst wrote:
> Mirja,
>
> Many thanks for your review. Since we got a number of people providing
> comments, we have tried to
> respond to many of the issues raised by updating the draft, but we
> may have missed something important, so see the specific responses
> below.
>
> Gorry
>
>  > Mirja Kuehlewind mirja.kuehlewind at ikr.uni-stuttgart.de
>  >
>  > 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)
>
> These values were to reduce the effects of variations in the measured
> FlightSize.
> There is not a significant impact on performance for the flow, so we wished
> to introduce hysteris, and avoid flapping between the two states. We
> wondered if the choice of 1/4 and 3/4 was more consistent, and could be
> handled easier
> by integer decision.
>
>  > - 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.
>
> OK checked these and rearranged section 4.3
>
>  > - 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
>
> Done.
>
>  > - 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
>
> The community has to date been quite resistant on how to do pacing etc,
> but I
> agree if there is consensus to add more detail here. For the moment, we
> cite Joe Touch et al's draft, although old this provides a starting point.
>
>  > - 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).
>
> It's true this could be large, we could rethink this, but the rationale
> was that in this current RTT the sender could have sent more, and given
> an application is likely to be variable rate, we should not try to cap
> at the mean-rate or anything like that. The value 2 may be more applicable
> for SS though. We're willing to discuss this one.
>
>  > - section 4.3.1: "cwnd = max(FlightSize*2, IW)"
>  > -> If you keep this, it should
>  > be  "cwnd = min(max(FlightSize*2, IW),cwnd)"
>
> We thought about this, but is it right? cwnd < IW, and hence the difference
> between the two terms is only important for some range of cwnd/2<FD<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?
>
> This is hopefully now clearer in the rearrangement.
>
>  > - section 4.3.2: Why is the reaction to congestion different
>  > than what should be done when leaving the nonvalidated phase?
>
> Because the sender needs to be more conservative
>
>  > - section 4.3.2: "cwnd = ((FlightSize - R)/2)" -> I wouldn't want to
>  > 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 any further while being
>  > application-limited!
>
> I think DTCP could be different, but this document should directly
> target TCP.
>
>  > - section 4.4: I would make this an own section 5
>
> Done.
>
>  > - section 4.4: Are there references available on what the "idle
>
> intervals of
>
>  > common applications"
>
> We only know what we have seen - more information would be useful, but I
> think
> that any app that goes idle for periods of many minutes >>5 is not going to
> suffer if it needs to do SS.
>
>  > and "period for which the capacity of an Internet path
>  > may commonly be regarded as stable" are?
>
> This caused us to look a lot, and it was best guess. The worst case,
> probably some pathological failure or a marginal wireless link is
> probably not
> that interesting. So this is a compromise.
>
>  > - 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".
>
> That would be cool with me, but I really do not think this signal exists
> unless
> the end host is the last system before the "problematic" link/router. I
> hesitate
> to try to predict what to do more generally.
>
>  > Maybe even require to monitor the RTT's
>  > and give a threshold when to disable this method.
>
> I think monitoring RTTs with variable rate traffic is not necessarily
> going to
> help a lot to detect anomolies, but combining several mechanisms together
> could help, is this just a little complicated for this case?
>
>  > - section 4.4: Also refer the respective TCP mechanisms that use a
>  > 5 minutes timer.
>
> We included an RFC ref for one.
>
>  > Mirja
>
> I do not know how best to deal with the burst issue you note, but I agree
> this is something that is desirable, but have evaded standards so far.
>
> 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
>  > tcpm at ietf.org
>  > 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] (Michael Welzl)
Date: Wed Aug  1 20:26:21 2012
Subject: [Iccrg] Draft minutes
Message-ID: <[email-masked]>

Hi all,

Please find below the minutes from the ICCRG meeting last Monday, here  
at the ongoing IETF. Speakers, everyone else who was there, I'd  
appreciate if you'd take a look and send me any fixes you think are  
necessary ASAP. I think you can actually edit them directly here:   http://etherpad.tools.ietf.org:9001/p/notes-ietf-84-iccrg?useMonospaceFont=true&showChat=false

I'll make end of this week the deadline, i.e. I'll finalize the  
minutes next Monday, 6 August.

Cheers,
Michael

****************************

Yuchung Cheng
Client-aided Congestion Management for TCP

Yuchung's presentation and slides described motivations, the
overall idea of doing CC across connections through CM, and
pros/cons of sender-side CM.  He described some reasons why
the client may be in a good position to help, which is what
the Great Snipe client-based CM framework is about, as the
subsequent slides describe.  There are a number of research
issues and opportunities.

Great Snipe is in early stages; source code is planned to be
released as it matures.

[Jim Gettys] - not one, but 2 bottlenecks in the home, 802.11
and broadband.  inside Linux and other OSes, there is a system
that tracks how fast a wireless link can go (minstrel), on a 50ms by
50ms basis, you have some idea how fast you can transmit;
thinking about this as a black box without that information
doesn't make sense to me

[Yuchung] - all this information is on the client-side or end
device and if we can leverage it to help the transport layer
that would be great; it is very difficult to do if we keep it
inside one connection

[Roland Bless] - didn't quite get how this differs from RFC
3124 (congestion manager).

[Yuchung] - was imagining that was based on server-side; the
problem is to share between servers within a farm is hard, so
the client may be a better point

[Tim Shepard] - had trouble following proposal; sender/server
and client/receiver terminology

[Yuchung] - trying to make a distinction NOW, in my talk, the
direction of data flow as always server to client

[Tim] - wasn't sure you've included upload case; I have a server
at home; wasn't sure this would work in general, or what you
intend

[Yuchung] - just picking up the common case of a web server
sitting in the cloud and a client behind a wireless or other
link

[Scott Bradner] - CM RFC is not limited to servers, but it is
sender-side.  As I recall, the reason CM didn't take off is
that there was no way to make sure the same paths were being
taken for each of the flows being managed

[Matt Mathis] - this is early formative stage; it's probably
the case that you need to do CC from both ends, which does
(I believe) fix some of the CM problems.  For many use-cases
you potentially control all applications on a single
bottleneck; it's an improvement even if you do better some of
the time and doing classical CC at the other end fixes the
problems

[Michael Welzl] - what are you planning to put into code?

[Yuchung] - still experimenting; quick answer is that I don't
know yet

[Matt] - still some major holes in the code

Grenville Armitage
FreBSD-based TCP CC research:
Delay-Gradient TCP
Modular TCP Framework

Presentation and slides describe work done on the FreeBSD TCP
stack, and aim to look for collaborators, testers, etc.  The
idea of delay-based TCP sensing onset of congestion through
variations in RTT was described, in the "CDG" algorithm
(CAIA Delay Gradient).  Many aspects of the design and some
results comparing to other algorithms were shown.  Code is
available in FreeBSD.

[Question] - impact of RED

[Kathie Nichols] - since you're looking at how RTT goes up
and down are you inverting fairness between different RTTs
when you have flows with different RTTs.

[Grenville] - haven't looked at it

[Kathie] - undershooting and getting worse throughput is another
thing to look at

[Grenville] - CDG will never obtain the same goodput that loss-based
algorithms will; we will always underestimate a bit.  the benefit
is that you can get pretty good throughput but will hammer the voip
and other interactive traffic less

[Kathie] - comparing against reno instead of cubic; cubic is pretty
widely used

[Grenville] - we don't have it in these slides, but showed that
cubic will hammer the link and is not a real win for home links

[Andrew McGregor/Ken Carlberg] - packet aggregation would lead to
fluxuation in RTT

[Mo Zanaty] - you want to operate under the no-loss case and be
parameterless; how do you reconcide those things?  in what cases are
you able to stay fully lossless

[Grenville] - there are a couple of magic numbers; we don't actually
revert to newreno per-se, we just use our shadow window to only back
off as much as newreno would have under the circumstances

[unknown 1] - how do you distinguish between congestion
and non-congestion loss

[Grenville] - a congestion loss happens when the delay gradients tell  
us that
there was congestion before the loss. there's a potential weakness in  
incorrectly
estimating that queues are still growing

[unknown 1] that may not be the wrong answer; on UDP RTCWEB side  
people think a
few percent loss is fine without reducing the rate; not sure anybody
has really analyzed this; likely related to bursts of other flows
starting up

[Matt Mathis] - have you looked at worst-case scenario (10s of
thousands of streaming customers) and a near-field bottleneck where
loss is correlated across flows

[Grenville] - haven't specifically looked; we would see a massive
gradient

[Matt] - jumping up assumes that I saw an old RTT; suppose I have a
new connection

[Grenville] - would have to think about that

[Andrew/Ingemar] - non-congestive loss in wifi and LTE is about 40%
in the raw channel, and it has its own mechanism for retransmission
to hide its underlying packet losses

[Grenville] - those turn into latency

[Andrew] - the scarce resource is permission to transmit at all, so
it does lead to latency but not as much as you think

[Bob Briscoe] - cubic hasn't got enough control signals at speed

agreement

Microphone switched to Lawrence Stewart to discuss the modular CC
framework in FreeBSD.  Discussed FreeBSD as an R&D platform.  The
implementation of the modular CC capability was discussed, inclucing
SIFTR, khelp/hhook

[Andrew/jabber-Michael Tuexen] - does it include SCTP?

[Lawrence] - TCP immediately is the focus, other protocols down the
track

[Andrew/Dave Taht] - when will we see codel in BSD?

[Lawrence] - soon; several people working on it

Matt Mathis
Laminar TCP and Related Problems

Matt discussed the current status of linux patch for Laminar, and
the list of possible add-ons.  Since some folks were in neither
TCPM nor Matt's presentations at the last IETF meeting, he gave
a brief overview of Laminar that isn't in the slides.

[Michael Welzl] - what is in the patch; full-featured TCP?

[Matt] - yes, it's essentially identical, except for a case where
it's slightly slower, related to congestion window validation, and
it doesn't do TSO the same way

Matt encourages people to play with the code and will find that
Laminar makes things better/easier.  Wants to hear how it
effects other people's work (making it easier or harder).

[email-masked] mailing list

[Lars Eggert] - we have time to talk about what we want to do
here that we didn't in TCPM

[Mirja] - is this going upstream?

[Matt] - this breaks anyone who knows the code well's intuition
about how the code works; breaking it into smaller pieces now,
but that intermediate kernel would require different debugging,
so it's more work to do it that way.  on the other hand, I have
a history of long-term support of patches off to the side that
eventually got imported

Jim Gettys

Jim discussed bufferbloat global research topics involving
measurements needed to tell if it's getting better/worse and
where it is.

Netflix streaming behavior is to pump out chunks of data every
10 seconds, not actually streaming

wants an adaptive AQM; Jim says he's throwing out questions, but
he doesn't have answers.  This is research to be done.

work on tools is needed

[Lars Eggert] - go to homenet and write a document about what
needs to be done

[Andrew McGregor]

[Dave Taht] - openwrt many models already supported

[Lars] - I need one that does fiber

[Jim] Wireless is often as bad as broadband or worse

Meeting adjourned 3PM local time