From bernard_aboba@hotmail.com Tue Aug 4 03:20:34 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67C0228C21D for ; Tue, 4 Aug 2009 03:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.475 X-Spam-Level: X-Spam-Status: No, score=-1.475 tagged_above=-999 required=5 tests=[AWL=1.123, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqHEpHAnfve3 for ; Tue, 4 Aug 2009 03:20:31 -0700 (PDT) Received: from blu0-omc4-s7.blu0.hotmail.com (blu0-omc4-s7.blu0.hotmail.com [65.55.111.146]) by core3.amsl.com (Postfix) with ESMTP id 0B5C128C315 for ; Tue, 4 Aug 2009 03:20:30 -0700 (PDT) Received: from BLU137-W5 ([65.55.111.137]) by blu0-omc4-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 03:20:29 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_75053a1a-b776-4813-b3d9-93cde02920ca_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: Date: Tue, 4 Aug 2009 03:20:29 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 04 Aug 2009 10:20:29.0693 (UTC) FILETIME=[3117D2D0:01CA14ED] Subject: [ledbat] Draft minutes of the LEDBAT WG meeting at IETF 75 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 10:20:34 -0000 --_75053a1a-b776-4813-b3d9-93cde02920ca_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable LEDBAT WG Meeting IETF 75 Stockholm=2C Sweden Wednesday=2C July 29=2C 2009 13:00 - 15:00 Congresshall B =20 Chairs: S. Shalunov M. Sridharan B. Aboba (acting) =20 Preliminaries (10 minutes) =20 Note well Blue Sheets Minute Takers (Matthew J Zekauskas=2C Al Morton) Jabber Scribe Agenda bashing Agenda Bash Iljitsch van Beijnum would like to get feedack from folks here=2C on the ap= propriate size of buffers in home gateways. See homegate@ietf.org=2C tsvar= ea discussion ongoing. Document Status No current WG documents. Three documents under consideration for adoption = at this meeting. =20 Documents Under Consideration for Adoption as a WG Work Item (80 minutes) 13:10 - 13:40 Low Extra Delay Background Transport (LEDBAT)=2C S. Shalunov= (30 minutes) http://tools.ietf.org/id/draft-shalunov-ledbat-congestion Doc hasn't changed from last time=2C but there was discussion on mailing li= st that we want to address. First=2C what are the goals? To saturate the = network=2C but keep delay low. Yielding to TCP and adding little extra dela= y are consequences of this=2C but we state them separately.=20 Stas gives an overview of the congestion control goals=2C some features in = Pseudo-code.=20 Receiver just keeps telling sender measured delay Sender is more complex. keeps delay low by measuring and reacting=2C notion of target delay. controller is a proportional-integral-derivative (PID) controller as safety measure=2C on loss=2C halve window. Question: what is the framing? UDP? TCP?=20 Answer: The congestion control mechanism is independent of framing. =20 In an early draft of the charter=2C UDP framing was specified. It is not i= n the current charter. UDP is the most expedient way to deploy LEDBAT=2C b= ut it could work over TCP as a modification (though timestamps would be req= uired).=20 Question: Can it work on top of the TCP control loop? Answer: Don't know=2C doesn't seem like a direct application=2C but not pa= rt of the WG charter. Could be a DCCP CCID=2C or SCTP modification/option= (timestamps required).=20 Lars: We can discuss framing after the algorithm has stabilized and people = have played with it (document is slated for Experimental). Once we have implementation experience=2C we will take it f= rom there.=20 Late-comer's advantage (or first mover's advantage):=20 Consider (general prob w/delay based congestion control=2C discussed w with= respect to TCP Vegas=2C fast.):=20 Latecomer could be deceived by outstanding queue=2C think base delay is hig= her than it is. The latecomer can't look inside the queue and see packets= =2C it only measures the delay. If have you have a stack of latecomers=2C = since they underestimate queue size=2C they could starve out the first move= rs. =20 When a sender experiences starvation=2C their estimated queue size is large= r=2C and they don't put traffic on the bottleneck=2C so the queue size will drop=2C and the latecomers will get a better baselin= e measurement. As a result=2C the latecomers queue size estimate will incr= ease and they will decrease their sending rate. So we think that the late = mover advantage will be short-lived. Such an advantage can be observed in = a simulator=2C but not in the wild=2C because in a simulator it is easy to = get phase-locked packets. In real networks you have more jitter=2C such as= disk seeks=2C which introduces randomness. More randomness increases the = probability of extreme conditions (e.g. minimum estimate of baseline delay)= . Perhaps the answer might be different for a huge number of flows. a high= er degree of statistical multiplexing. But with a few hundred flows=2C di= ps will show up regularly.=20 Rich Moody=2C Comcast: any measurements to confirm this behavior? Stas: fairness seems to be preserved. No studies showing measurements in= the wild. Lars: The question asked for an Experimental status is: "Will this be sa= fe on the Internet?" However=2C the longer-term=20 question is whether this will be effective in reducing Queue size. Rich's 2nd Question: any hardware dependencies? If we move to solid stat= e storage instead of hard drives=2C so that seek times decrease=2C do the dips go away? Stas: Operating systems schedulers still introduce jitter in user space= =2C no way around that. =20 Matt Z: you can see this kind of RATE dip on Internet traffic today. Stas: You select the target=2C such that multiplication by the number of = flows works. You don't multiply the Target by the number of flows. All fl= ows target the same delay=2C whether there is one flow or fifteen.=20 Rich again: do all apps have to use the same queuing delay target? If they= pick different queuing delay targets=2C does that work? Fairness by random redistribution The current draft does not contain this discussion=2C this will be fixed. How do multiple flows end up sharing the queue and why? As a thought experiment: suppose we want as a design goal to redistribute = a bit of capacity from connections randomly=2C while keeping same total tar= get link capacity. It is intuitively clear=2C and can be easily shown rigo= rously=2C that this could be accomplished by introducing randomness in meas= urement. Instead of using the measured delay=2C add a random quantity to i= t=2C which doesn't have to be large. =20 Whatever we need to redistribute=2C say 10 percent of RTT. Error needs to b= e a fraction of the target that's equal to # packets in RTT/10 in that case= . This is a very small fraction. If there are few packets in RTT and the t= arget is 25ms queuing delay=2C we are talking about sub-ms errors. So the question is whether randomness is there=2C such as in phase of arri= val of serialization with respect to the prevous packet. This is the same = randomness that causes dips to appear (and evens out the estimates of base = delay).=20 lars: related work=2C RFC 5148=2C MANET. talks about jittering timers in r= outing protocols for different purpose=2C but effect is the same. Parameter Values Choice of parm values is a little more interesting.=20 Two parameters here: GAIN and TARGET. All values on the slide are "not insane". For various definitions of "work"=2C all work. We can go further beyond these ranges. But how do we choose?=20 Choice of GAIN is more arbitrary than choice of TARGET. GAIN: how fast do you converge=2C how stable is it. large value of GAIN ->= fast convergence=2C small value ->stable. 1 MSS/RTT and 10 MSS/RTT are both conservative. 1 has interesting property: if delay measurement is completely broken=2C an= d zero queuing delay is always measured=2C this replicates the ramp up of a= single TCP flow. This is why the value 1 was chosen originally=2C since w= e know that if we ramp up as with a single TCP flow=2C the world doesn't en= d.=20 TARGET: is less arbitrary. There is a wide range of potential values that = are all sane. The numbers in the draft work=2C but aren't magic. =20 Higher target values are more robust: you get a smaller relative error for = any absolute error Lower target values add less delay=3B clearly there are diminishing return= s. Going from 1 sec to 0.5 sec queueing delays=2C is a huge difference for int= eractive users Going from 2 ms to 1ms queueing delay makes no difference whatsoever. 1ms is way too low=2C it is not a value that wold work=2C so that is just a= n example. Human reaction/perception threshold seems like a useful reference. Add or subtract typical RTT=2C don't add much of a disservice. Unless you are a pro gamer=2C you probably can't notice a difference of 25m= s in ping time. Why is 25ms there? Could we make it 10 or 50ms? Yes.=20 Ted Hardie: thank you for not having magic numbers in your head. For human= perception in applications it is rarely a single flow that is taken into a= ccount before presenting to the end user. This is true for large video flo= ws=2C but for other applications=2C a combination of multiple things typica= lly will cause UI actions to appears. Hundreds of different web sites can = be required to render a single web page in extreme cases.=20 Stas: another useful benchmark=2C not on the slide=2C is the speed of ligh= t limit on RTT=2C which is not a very large fraction of Internet delay. =20 Lars: want to disagree with Ted a bit. If directly connected to server=2C = and add this=2C making that server look 25ms away=2C is OK. 100 to 125ms i= s probably ok. We are not multiplying by the number of flows. Sean Doran: Let me pile on Ted. Are the magic numbers for humans? For au= dio=2C less than 70ms is useless.=20 Ted: I disagree with Lars. In the case of a web page=2C you must go and fe= tch the links to render the page=2C and that might involve redirects to oth= er sites. Each additional 25ms delay can start to add up to a long renderi= ng time=2C which is perceptible by the user. We could be talking about 30 = RTT=2C which is not small.=20 Lars: if we are in TCP slow start=2C each RTT might be longer. If we move = the server 25ms further away from you=2C in many use cases=2C it will not m= atter=2C but there are some cases where it does: NFS. Think of this as ad= ding 3000km physical distance. For some applications that is a big deal.=20 Bruce Lowekamp: multiply the target by # flows. Does that assume that ther= e is a single bottleneck for all flows=2C or all have same destination? Stas: We are not assuming that. A single bottleneck is the typical case=2C= but if not=2C there is no multiplicative effect. =20 Fairness by Random Re-distribution: Stas:=20 Lars - there is some re-synchronization =2C has worked well in other scenar= ios. Parameter Values=2C Gain and Target: Gain =3D how fast you converge=2C and how stable=2C can be more arbitrary t= han Target. Target delay has several considerations=2C Human perception Benchmarks?? Ted (finally) the delays=2C even small=2C can add-up=20 Dave Oran - there are Magic numbers=2C < 70 ms delay imperceptible for voic= e Lars got clarification of Ted's comments. POLL: Adopt this a WG Item - 18 for adoption=2C none against.=20 Consensus to be verified on the list.=20 13:40 - 14:10 LEDBAT Practices and Recommendations=2C R. Penno (30 minutes) http://tools.ietf.org/id/draft-penno-ledbat-app-practices-recommendations R. Penno is ill and so cannot present. We will go over the slides from IET= F 74 again. The document has not been revised since IETF 74.=20 Stuart Cheshire: it is not clear that multiple parallel connections result = in higher throughput. I think that is a common fallacy=2C particularly on = lossy networks. If there is not enough data to trigger fast retransmit=2C = the whole thing slows down.=20 Stas: As a general question=2C I'd like to hear the WG opinion on how much= this draft should describe practices=2C and how much it should make recomm= endations. In other words=2C do we need a better survey=2C or better guid= ance?=20 Lars: when we wrote the charter=2C we wanted recommendations. We saw confu= sion out there. Stuart just illustrated once such issue. So having the IE= TF comment on this would be useful.=20 Stas: Personally I think the document doesn't contain enugh recommendations= =2C but just collects evidence. We stil have to work on recommendations.=20 Bob Briscoe: To come back to Stuart's point: 1. Educate and explain. =20 2. Recommendations may be difficult. =20 Stuart: multiple connections get bad performance=2C if each only has a few = packets and also if they are not using full size packets=2C then packing in= stream.=20 Bob Briscoe: Oh=2C I misheard. I agree! Stas: if one connection gets all the throughput you should be getting=2C mo= re connections will not help you. Stuart: more connections does help when parallel connections get a bigger p= art of congested link. But my sense is those cases are fairly rare. When = Mosaic did it=2C we only had HTTP 1.0 and could not pipeline GETs. Now a d= ays=2C you can send 16 GET Requests over a single TCP connection=2C which i= s much faster than opening 16 connections=2C each with one GET.=20 Mac Ivess: made point in ICCRG=2C MULTITCP=2C gave upper limit of 6 based o= n some data from infocom paper. think could be used for some of these=2C t= his gives a rough view. stas: Les Cottrell from SLAC did some measurements. Where connections were= windowlimited mostly=2C very clear that dropoff past certain point. Start= losing perf=2C even when trying to saturate link with connections. Get pa= st 10-20 connections and performance goes down. These are somewhat similar= . Bob Briscoe: this depends on if you have a shared link or a self-congested = link. Self-congested=2C won't=3B shared=2C may. Stuart: one quick final comment=2C given that we are designing protocols th= at everyone uses. If one person is greedy=2C they get a bigger share. If = everyone is greedy=2C we're back to square one=2C but we're more inefficien= t.=20 Stas: It is clear that in the doc=2C trying to be greedy gets more out of a= congested bottleneck=2C but that is not a good reason to use multiple conn= ections. Only classic product that opens multiple connections to get bigge= r share=2C is download mgr. Bob Briscoe: We can't tell intent at build time=3B we don't know if we have= a shared link or a self-congested link. No matter what the intent is=2C i= t might get misused in another situation. To reinforce Stuart: when we sta= rt an arms race=2C TCP squares the amount of congestion. If everyone puts = in 2 more=2C we get 4 times. 10 more=2C 100 times=2C and then "congestive = collapse".=20 Comcast: I have a more fundamental question about this document. Is it und= er active authorship? Are the authors continuing? They didn't update the = document=2C and they aren't here to present it. There is clearly a lot of = work to do.=20 Stas: I don't have an update on the status. If it turns out that we need m= ore contributors or another editor=2C it is easier to do if it is a WG docu= ment under IETF change control. The WG can't find an editor for a non-WG d= ocument.=20 Lars: since there is no WG work item yet in this area=2C if someone wrote a= document that the WG liked better=2C that would move forward. If it is a = WG work item=2C we could talk about replacing the editor. =20 Stas: We did talk to the editor and he wanted it to become a WG work item. = He is in Stockholm=2C but has fallen ill. =20 Lars: that explains why he is not presenting=2C but not why there is no upd= ate. I hate to step on somebody's toes=2C but I'm hesitant if there is a la= ck of editing cycles and the document is not a WG work item. This is a sit= uation where we frequently run into problems.=20 Bernard: Who is interested in working on this document and contributing to= it?=20 2 folks raise their hands (Vijay and Comcast attendee).=20 Stas: This shall not go unpunished.=20 Who thinks this document should be accepted as a WG work item?=20 Zero hands.=20 Who thinks it should not be accepted? Two hands.=20 Vijay: Since IETF 74=2C there has been no update=2C and it needed more wor= k. =20 Lars: Let's get a sense of how to move forward. If the document were to b= e updated a few times=2C would people think it could be ready=2C or will th= e document never be ready?=20 Who thinks it would be ready if worked on some more? 11 people raise their hands.=20 Who thinks that no matter how much effort does into it=2C something is fund= amentally wrong?=20 Zero hands raised.=20 Clear message: get an active editor and put in cycles. =20 14:10 - 14:30 A Survey of Lower-than-Best Effort Transport Protocols=2C M. = Welzl (20 minutes) http://tools.ietf.org/html/draft-welzl-ledbat-survey This document is a literature review=2C to help us avoid reinventing the wh= eel. The document looks at delay-based congestion algorithms=2C as well as= application layer mechanisms.=20 delay based algorithms TCP Vegas. not designed to be lower than best efforts (LBE). But nice= example=2C LBE in presence of Reno=2C but better if it is the only one. =20 Others based on Vegas=2C but designed for LBE: TCP Nice=2C TCP-LP non-delay based Also designed to give way=2C though=2C growing less than TCP.=20 4CP=2C uses virtual window to limit congestion window earlier MulTFRC. =20 0.1 weight. 10x less agressive. But requires queue growth=2C reacts= only to losses. app layer approaches. so far=2C rcv window tuning. Some quite sophisticated ones see SIGMETRICS 04 paper. claim: could work as well as transport-layer scheme Bernard: This document is under consideration for adoption as a WG work it= em. Who wants to see it adopted? Lars: This would be informational.=20 18 hands. Who doesn't want to see it adopted No hands.=20 =3D=3D=3D=3D 5 minute Item - Home Gate Iljitsch van Beijnum=20 Bar BOF Monday on home gateways: HOMEGATE. There is no charter=2C all is u= p in the air. =20 How much buffering should be in Home Gateways?=20 Wants people to send their info and thoughts about buffering and queueing s= trategies. join homegate@ietf.org or send feedback to Iljitsch: www.ietf.org/mailman/listinfo/homegate Stas - don't do things in HOMEGATE that make LEDBAT's job harder. Very sma= ll buffer would make congestion control more difficult. Prefer the "Do no = harm" criteria for recommendations. Bob Briscoe: Weighted Fair Queuing isn't designed for Homegateways -- don't= isolate the apps from each other. Mark Handley - very small buffers on GigE links with high stat mux Rich Moody - 10 packets may not be enough buffer=2C 150ms to 200ms worth <1= 00 but more than 10 packets... Dave Oran - the box that controls L2 state (e.g. 802.11 power save bufferin= g) has no interaction with the device L3 queuing. Think Cable Modem "Comcast=2C it's our fault." back to the Rich moody comme= nt above=2C need longer queue sometimes. Next Steps and Wrapup (30 minutes) 14:30 - 15:00 Chairs & Area Directors (30 minutes) Nothing to Discuss - all votes were Unanimous. --_75053a1a-b776-4813-b3d9-93cde02920ca_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable LEDBAT WG Meeting
IETF 75
Stockholm=2C Sweden

Wednesday=2C Jul= y 29=2C 2009
13:00 - 15:00
Congresshall B
 =3B =3B =3B=  =3B =3B =3B =3B =3B =3B
Chairs: =3B S. Sha= lunov
 =3B =3B =3B =3B =3B =3B =3B =3B M= . Sridharan
 =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B B. Aboba (acting)
 =3B =3B =3B =3B =3B =3B&= nbsp=3B =3B =3B
Preliminaries (10 minutes)
 =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B
 =3B = =3B =3B =3B =3B =3B =3B =3B Note well
 =3B&n= bsp=3B =3B =3B =3B =3B =3B =3B Blue Sheets
 = =3B =3B =3B =3B =3B =3B =3B =3B Minute Takers (= Matthew J Zekauskas=2C Al Morton)
 =3B =3B =3B =3B = =3B =3B =3B =3B Jabber Scribe
 =3B =3B =3B = =3B =3B =3B =3B =3B Agenda bashing

Agenda Bash
Iljitsch van Beijnum would like to get feedack from folks here=2C on the = appropriate size of buffers in home gateways. =3B See homegate@ietf.org= =2C tsvarea discussion ongoing.

Document Status

No current WG= documents. =3B Three documents under consideration for adoption at thi= s meeting.
 =3B =3B =3B =3B =3B =3B =3B = =3B =3B
Documents Under Consideration for Adoption as a WG Work Ite= m (80 minutes)

13:10 - 13:40 Low Extra Delay Background =3B Tran= sport (LEDBAT)=2C S. Shalunov (30 minutes)
http://tools.ietf.org/id/draf= t-shalunov-ledbat-congestion

Doc hasn't changed from last time=2C bu= t there was discussion on mailing list that we want to address. =3B Fir= st=2C what are the goals? =3B To saturate the network=2C but keep delay= low. Yielding to TCP and adding little extra delay are consequences of thi= s=2C but we state them separately.

Stas gives an overview of the co= ngestion control goals=2C some features in Pseudo-code.
Receiver just k= eeps telling sender measured delay
Sender is more complex.
 =3B k= eeps delay low by measuring and reacting=2C notion of target delay.
&nbs= p=3B controller is a proportional-integral-derivative (PID) controller
&= nbsp=3B as safety measure=2C on loss=2C halve window.

Question: = =3B what is the framing? =3B UDP? =3B TCP?
Answer: =3B The = congestion control mechanism is independent of framing. =3B
In an e= arly draft of the charter=2C UDP framing was specified. =3B It is not i= n the current charter. =3B UDP is the most expedient way to deploy LEDB= AT=2C but it could work over TCP as a modification (though timestamps would= be required).
Question: =3B Can it work on top of the TCP control = loop?
Answer: =3B Don't know=2C doesn't seem like a direct applicati= on=2C but not part of the WG charter. =3B =3B Could be a DCCP CCID= =2C or SCTP modification/option (timestamps required).
Lars: We can dis= cuss framing after the algorithm has stabilized and people have played with= it (document is slated for
Experimental). =3B Once we have implemen= tation experience=2C we will take it from there.

Late-comer's advan= tage (or first mover's advantage):

Consider (general prob w/delay b= ased congestion control=2C discussed w with respect to TCP Vegas=2C fast.):=
Latecomer could be deceived by outstanding queue=2C think base delay i= s higher than it is. =3B =3B The latecomer can't look inside the qu= eue and see packets=2C it only measures the delay. =3B If have you have= a stack of latecomers=2C since they underestimate queue size=2C they could= starve out the first movers. =3B

When a sender experiences sta= rvation=2C their estimated queue size is larger=2C and they don't put traff= ic on the bottleneck=2C
so the queue size will drop=2C and the latecomer= s will get a better baseline measurement. =3B As a result=2C the lateco= mers queue size estimate will increase and they will decrease their sending= rate. =3B So we think that the late mover advantage will be short-live= d. =3B Such an advantage can be observed in a simulator=2C but not in t= he wild=2C because in a simulator it is easy to get phase-locked packets.&n= bsp=3B In real networks you have more jitter=2C such as disk seeks=2C which= introduces randomness. =3B More randomness increases the probability o= f extreme conditions (e.g. minimum estimate of baseline delay). Perhaps the= answer might be different for a huge number of flows. =3B a higher deg= ree of statistical multiplexing. =3B But with a few hundred flows=2C&nb= sp=3B dips will show up regularly.

 =3B Rich Moody=2C Comcast: = any measurements to confirm this behavior?
 =3B Stas: fairness seems= to be preserved. =3B No studies showing measurements in the wild.
&= nbsp=3B Lars: =3B The question asked for an Experimental status is: "Wi= ll this be safe on the Internet?" =3B However=2C the longer-term
&n= bsp=3B =3B =3B =3B =3B =3B =3B =3B question is = whether this will be effective in reducing Queue size.

 =3B Rich= 's 2nd Question: any hardware dependencies? =3B If we move to solid sta= te storage instead of hard drives=2C so that seek
 =3B =3B = =3B =3B =3B =3B times decrease=2C do the dips go away?
 = =3B Stas: =3B Operating systems schedulers still introduce jitter in us= er space=2C no way around that. =3B
 =3B Matt Z: you can see th= is kind of RATE dip on Internet traffic today.

 =3BStas: =3B= You select the target=2C such that multiplication by the number of flows w= orks. =3B You don't multiply the Target by the number of flows. =3B= All flows target the same delay=2C whether there is one flow or fifteen. <= br> =3BRich again: do all apps have to use the same queuing delay targe= t? If they pick different queuing delay targets=2C does that work?

F= airness by random redistribution

The current draft does not contain = this discussion=2C this will be fixed.
How do multiple flows end up shar= ing the queue and why?

As a thought experiment: =3B suppose we w= ant as a design goal to redistribute a bit of capacity from connections ran= domly=2C while keeping same total target link capacity. =3B It is intui= tively clear=2C and can be easily shown rigorously=2C that this could be ac= complished by introducing randomness in measurement. =3B Instead of usi= ng the measured delay=2C add a random quantity to it=2C which doesn't have = to be large. =3B

Whatever we need to redistribute=2C say 10 per= cent of RTT. Error needs to be a fraction of the target that's equal to # p= ackets in RTT/10 in that case. =3B This is a very small fraction. If th= ere are few packets in RTT and the target is 25ms queuing delay=2C we are t= alking about sub-ms errors.

So the question is whether randomness is= there=2C such as in =3B phase of arrival of serialization with respect= to the prevous packet. =3B This is the same randomness that causes dip= s to appear (and evens out the estimates of base delay).

lars: rela= ted work=2C RFC 5148=2C MANET. =3B talks about jittering timers in rout= ing protocols for different purpose=2C but effect is the same.

Param= eter Values

Choice of parm values is a little more interesting.
= Two parameters here: GAIN and TARGET.
All values on the slide are "not i= nsane".
For various definitions of "work"=2C all work.
We can go furt= her beyond these ranges. =3B But how do we choose?

Choice of GA= IN is more arbitrary than choice of TARGET.
GAIN: how fast do you conver= ge=2C how stable is it. =3B large value of GAIN ->=3Bfast convergence= =2C small value ->=3Bstable.
1 MSS/RTT and 10 MSS/RTT are both conserv= ative.
1 has interesting property: if delay measurement is completely br= oken=2C and zero queuing delay is always measured=2C this replicates the ra= mp up of a single TCP flow. =3B This is why the value 1 was chosen orig= inally=2C since we know that if we ramp up as with a single TCP flow=2C the= world doesn't end.

TARGET: is less arbitrary. =3B There is a w= ide range of potential values that are all sane. =3B The numbers in the= draft work=2C but aren't magic. =3B

Higher target values are m= ore robust: you get a smaller relative error for any absolute error
Lowe= r target values add less delay=3B =3B clearly there are diminishing ret= urns.
Going from 1 sec to 0.5 sec queueing delays=2C is a huge differenc= e for interactive users
Going from 2 ms to 1ms queueing delay makes no d= ifference whatsoever.
1ms is way too low=2C it is not a value that wold = work=2C so that is just an example.

Human reaction/perception thresh= old seems like a useful reference.
Add or subtract typical RTT=2C don't = add much of a disservice.
Unless you are a pro gamer=2C you probably can= 't notice a difference of 25ms in ping time.
Why is 25ms there? =3B = Could we make it 10 or 50ms? =3B Yes.

Ted Hardie: thank you for= not having magic numbers in your head. =3B For human perception in app= lications it is rarely a single flow that is taken into account before pres= enting to the end user. =3B This is true for large video flows=2C but f= or other applications=2C a combination of multiple things typically will ca= use UI actions to appears. =3B Hundreds of different web sites can be r= equired to render a single web page in extreme cases.

Stas: =3B= another useful benchmark=2C not on the slide=2C is the speed of light limi= t on RTT=2C which is not a very large fraction of Internet delay. =3B <= br>
Lars: want to disagree with Ted a bit. =3B If directly connected= to server=2C and add this=2C making that server look 25ms away=2C is OK.&n= bsp=3B 100 to 125ms is probably ok. =3B We are not multiplying by the n= umber of flows.

Sean Doran: =3B Let me pile on Ted. =3B Are = the magic numbers for humans? =3B For audio=2C less than 70ms is useles= s.

Ted: I disagree with Lars. =3B In the case of a web page=2C = you must go and fetch the links to render the page=2C and that might involv= e redirects to other sites. =3B Each additional 25ms delay can start to= add up to a long rendering time=2C which is perceptible by the user. = =3B We could be talking about 30 RTT=2C which is not small.

Lars: i= f we are in TCP slow start=2C each RTT might be longer. =3B If we move = the server 25ms further away from you=2C in many use cases=2C it will not m= atter=2C but there are some cases where it does: =3B NFS. =3B Think= of this as adding 3000km physical distance. For some applications that is = a big deal.

Bruce Lowekamp: multiply the target by # flows. =3B= Does that assume that there is a single bottleneck for all flows=2C or all= have same destination?

Stas: We are not assuming that. =3B A si= ngle bottleneck is the typical case=2C but if not=2C there is no multiplica= tive effect. =3B

Fairness by Random Re-distribution:
Stas: <= br>Lars - there is some re-synchronization =2C has worked well in other sce= narios.

Parameter Values=2C Gain and Target:
Gain =3D how fast yo= u converge=2C and how stable=2C can be more arbitrary than Target.
Targe= t delay has several considerations=2C Human perception Benchmarks??
Ted = (finally) the delays=2C even small=2C can add-up
Dave Oran - there are = Magic numbers=2C <=3B 70 ms delay imperceptible for voice
Lars got cla= rification of Ted's comments.

POLL: =3B Adopt this a WG Item&nbs= p=3B - 18 for adoption=2C none against.
Consensus to be verified on the= list.

13:40 - 14:10 LEDBAT Practices and Recommendations=2C R. Pen= no (30 minutes)
http://tools.ietf.org/id/draft-penno-ledbat-app-practice= s-recommendations

R. Penno is ill and so cannot present. =3B We = will go over the slides from IETF 74 again. =3B The document has not be= en revised since IETF 74.

Stuart Cheshire: it is not clear that mul= tiple parallel connections result in higher throughput. =3B I think tha= t is a common fallacy=2C particularly on lossy networks. =3B If there i= s not enough data to trigger fast retransmit=2C the whole thing slows down.=

Stas: =3B As a general question=2C I'd like to hear the WG opi= nion on how much this draft should describe practices=2C and how much it sh= ould make recommendations. =3B =3B In other words=2C do we need a b= etter survey=2C or better guidance?

Lars: when we wrote the charter= =2C we wanted recommendations. =3B We saw confusion out there. =3B = Stuart just illustrated once such issue. =3B So having the IETF comment= on this would be useful.

Stas: Personally I think the document doe= sn't contain enugh recommendations=2C but just collects evidence. =3B W= e stil have to work on recommendations.

Bob Briscoe: To come back t= o Stuart's point:
 =3B 1. =3B Educate and explain. =3B
&= nbsp=3B 2. =3B Recommendations may be difficult. =3B

Stuart= : multiple connections get bad performance=2C if each only has a few packet= s and also if they are not using full size packets=2C then packing in strea= m.

Bob Briscoe: =3B Oh=2C I misheard. =3B I agree!

S= tas: if one connection gets all the throughput you should be getting=2C mor= e connections will not help you.

Stuart: more connections does help = when parallel connections get a bigger part of congested link. =3B But = my sense is those cases are fairly rare. =3B When Mosaic did it=2C we o= nly had HTTP 1.0 and could not pipeline GETs. =3B Now a days=2C you can= send 16 GET Requests over a single TCP connection=2C which is much faster = than opening 16 connections=2C each with one GET.

Mac Ivess: made p= oint in ICCRG=2C MULTITCP=2C gave upper limit of 6 based on some data from = infocom paper. =3B think could be used for some of these=2C this gives = a rough view.

stas: Les Cottrell from SLAC did some measurements.&nb= sp=3B Where connections were windowlimited mostly=2C very clear that dropof= f past certain point. =3B Start losing perf=2C even when trying to satu= rate link with connections. =3B Get past 10-20 connections and performa= nce goes down. =3B These are somewhat similar.

Bob Briscoe: this= depends on if you have a shared link or a self-congested link. Self-conges= ted=2C won't=3B shared=2C may.

Stuart: one quick final comment=2C gi= ven that we are designing protocols that everyone uses. =3B If one pers= on is greedy=2C they get a bigger share. =3B If everyone is greedy=2C w= e're back to square one=2C but we're more inefficient.

Stas: It is = clear that in the doc=2C trying to be greedy gets more out of a congested b= ottleneck=2C but that is not a good reason to use multiple connections.&nbs= p=3B Only classic product that opens multiple connections to get bigger sha= re=2C is download mgr.

Bob Briscoe: We can't tell intent at build ti= me=3B we don't know if we have a shared link or a self-congested link. = =3B No matter what the intent is=2C it might get misused in another situati= on. =3B To reinforce Stuart: when we start an arms race=2C TCP squares = the amount of congestion. =3B If everyone puts in 2 more=2C we get 4 ti= mes. =3B 10 more=2C 100 times=2C and then "congestive collapse".
Comcast: I have a more fundamental question about this document. =3B = Is it under active authorship? =3B Are the authors continuing? =3B = They didn't update the document=2C and they aren't here to present it. = =3B There is clearly a lot of work to do.

Stas: I don't have an upd= ate on the status. =3B If it turns out that we need more contributors o= r another editor=2C it is easier to do if it is a WG document under IETF ch= ange control. =3B The WG can't find an editor for a non-WG document.
Lars: since there is no WG work item yet in this area=2C if someone w= rote a document that the WG liked better=2C that would move forward. = =3B If it is a WG work item=2C we could talk about replacing the editor.&nb= sp=3B

Stas: We did talk to the editor and he wanted it to become a = WG work item. =3B He is in Stockholm=2C but has fallen ill. =3B Lars: that explains why he is not presenting=2C but not why there is no up= date. I hate to step on somebody's toes=2C but I'm hesitant if there is a l= ack of editing cycles and the document is not a WG work item. =3B This = is a situation where we frequently run into problems.

Bernard: = =3B Who is interested in working on this document and contributing to it? <= br>2 folks raise their hands (Vijay and Comcast attendee).
Stas: = =3B This shall not go unpunished.

Who thinks this document should b= e accepted as a WG work item?
Zero hands.
Who thinks it should not = be accepted?
Two hands.

Vijay: =3B Since IETF 74=2C there ha= s been no update=2C and it needed more work. =3B
Lars: =3B Let'= s get a sense of how to move forward. =3B If the document were to be up= dated a few times=2C would people think it could be ready=2C or will the do= cument never be ready?

Who thinks it would be ready if worked on so= me more?
11 people raise their hands.

Who thinks that no matter = how much effort does into it=2C something is fundamentally wrong?
Zero = hands raised.

Clear message: get an active editor and put in cycles= .
 =3B =3B =3B =3B =3B =3B =3B =3B = =3B
14:10 - 14:30 A Survey of Lower-than-Best Effort Transport Protocol= s=2C M. Welzl (20 minutes)
http://tools.ietf.org/html/draft-welzl-ledbat= -survey

This document is a literature review=2C to help us avoid rei= nventing the wheel. =3B The document looks at delay-based congestion al= gorithms=2C as well as application layer mechanisms.

delay based al= gorithms
 =3B =3B =3B TCP Vegas. =3B not designed to be = lower than best efforts (LBE). =3B But nice example=2C LBE in presence = of Reno=2C but better if it is the only one. =3B

 =3B = =3B =3B Others based on Vegas=2C but designed for LBE: TCP Nice=2C TCP-= LP

non-delay based
 =3B Also designed to give way=2C though= =2C growing less than TCP.
 =3B 4CP=2C uses virtual window to limit= congestion window earlier
 =3B MulTFRC. =3B
 =3B = =3B =3B =3B =3B 0.1 weight. =3B 10x less agressive. =3B= But requires queue growth=2C reacts only to losses.

app layer appro= aches.
 =3B so far=2C rcv window tuning. =3B Some quite sophisti= cated ones
 =3B see SIGMETRICS 04 paper.
 =3B =3B claim: = could work as well as transport-layer scheme

Bernard: =3B This d= ocument is under consideration for adoption as a WG work item. =3B = =3B Who wants to see it adopted?
Lars: =3B This would be information= al.

18 hands.
Who doesn't want to see it adopted
No hands.
=3D=3D=3D=3D
5 minute Item - Home Gate
Iljitsch van Beijnum
Bar BOF Monday on home gateways: =3B HOMEGATE. There is no charter= =2C all is up in the air. =3B
How much buffering should be in Home = Gateways?
Wants people to send their info and thoughts about buffering = and queueing strategies.
join homegate@ietf.org or send feedback to Ilji= tsch:
www.ietf.org/mailman/listinfo/homegate <=3Bhttp://www.ietf.org/m= ailman/listinfo/homegate>=3B

Stas - don't do things in HOMEGATE th= at make LEDBAT's job harder. =3B Very small buffer would make congestio= n control more difficult. Prefer the =3B "Do no harm" criteria for reco= mmendations.

Bob Briscoe: Weighted Fair Queuing isn't designed for H= omegateways -- don't isolate the apps from each other.
Mark Handley - ve= ry small buffers on GigE links with high stat mux
Rich Moody - 10 packet= s may not be enough buffer=2C 150ms to 200ms worth <=3B100 but more than = 10 packets...
Dave Oran - the box that controls L2 state (e.g. 802.11 po= wer save buffering) has no interaction with the device L3 queuing.
Think= Cable Modem "Comcast=2C it's our fault." back to the Rich moody comment ab= ove=2C need longer queue sometimes.


Next Steps and Wrapup (30 mi= nutes)

14:30 - 15:00 Chairs &=3B Area Directors (30 minutes)
<= br>Nothing to Discuss - all votes were Unanimous.





 = --_75053a1a-b776-4813-b3d9-93cde02920ca_-- From michawe@ulrik.uio.no Tue Aug 4 04:54:58 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AE9628C3A9 for ; Tue, 4 Aug 2009 04:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.103 X-Spam-Level: X-Spam-Status: No, score=-6.103 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4B9asCogVB8l for ; Tue, 4 Aug 2009 04:54:57 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by core3.amsl.com (Postfix) with ESMTP id 7BF5A28C3AE for ; Tue, 4 Aug 2009 04:54:03 -0700 (PDT) Received: from mail-mx5.uio.no ([129.240.10.46]) by mail-out2.uio.no with esmtp (Exim 4.69) (envelope-from ) id 1MYIah-0004yn-Cd; Tue, 04 Aug 2009 13:54:03 +0200 Received: from w3prod-wm02.uio.no ([129.240.4.215] helo=webmail.uio.no) by mail-mx5.uio.no with esmtpsa (TLSv1:AES256-SHA:256) user michawe (Exim 4.69) (envelope-from ) id 1MYIag-0005j4-RG; Tue, 04 Aug 2009 13:54:03 +0200 Received: from 84.208.169.19 (SquirrelMail authenticated user michawe) by webmail.uio.no with HTTP; Tue, 4 Aug 2009 13:54:02 +0200 Message-ID: <895a41888a137e676855ac7a0ae4eb4d.squirrel@webmail.uio.no> In-Reply-To: References: Date: Tue, 4 Aug 2009 13:54:02 +0200 From: michawe@ifi.uio.no To: "Bernard Aboba" User-Agent: SquirrelMail/1.4.19 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-UiO-Ratelimit-Test: rcpts/h 12 msgs/h 5 sum rcpts/h 14 sum msgs/h 6 total rcpts 2405 max rcpts/h 33 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 63F8438145595B3F58C245DB6B633C6C93E59363 X-UiO-SPAM-Test: remote_host: 129.240.4.215 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 300 total 1540837 max/h 707 blacklist 0 greylist 0 ratelimit 0 Cc: ledbat@ietf.org Subject: Re: [ledbat] Draft minutes of the LEDBAT WG meeting at IETF 75 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 11:54:58 -0000 Small fix - which gave me a good laugh: > Mac Ivess: made point in ICCRG, MULTITCP, gave upper limit of 6 based on > some data from infocom paper. think could be used for some of these, this > gives a rough view. This dubious "Mac Ivess" seems to be me, Michael Welzl; and I talked about MulTFRC, not "MULTITCP". Mac Ivess, hehehe :-) I like that name. Maybe I should start using it as a pseudonym? I have to say, it sounds cooler to me than my real name cheers, Michael From richard_woundy@cable.comcast.com Tue Aug 4 05:55:08 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 510633A692C for ; Tue, 4 Aug 2009 05:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXD+sKPAM7XE for ; Tue, 4 Aug 2009 05:55:07 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 7D02A28C3AB for ; Tue, 4 Aug 2009 05:53:41 -0700 (PDT) Received: from ([24.40.15.92]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.48316743; Tue, 04 Aug 2009 08:53:19 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 08:53:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Tue, 4 Aug 2009 08:52:54 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ledbat] Draft minutes of the LEDBAT WG meeting at IETF 75 Thread-Index: AcoU+nQGAh6yr5w4S/W1PrksWvAHEQACAfa+ From: "Woundy, Richard" To: , X-OriginalArrivalTime: 04 Aug 2009 12:53:20.0433 (UTC) FILETIME=[8B47B210:01CA1502] Cc: ledbat@ietf.org Subject: Re: [ledbat] Draft minutes of the LEDBAT WG meeting at IETF 75 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 12:55:08 -0000 TWljaGFlbCwgdGhhdCdzIG11Y2ggY29vbGVyIHRoYW4gbXkgcHNldWRvbnltIGZyb20gdGhlIG1p bnV0ZXM6DQoNCj5SaWNoIE1vb2R5LCBDb21jYXN0OiBhbnkgbWVhc3VyZW1lbnRzIHRvIGNvbmZp cm0gdGhpcyBiZWhhdmlvcj8NCg0KTWFjIEl2ZXNzIHNvdW5kcyBsaWtlIGFuIGludGVybmF0aW9u YWwgc3B5LCBidXQgUmljaCBNb29keSBzb3VuZHMgbGlrZSBhIGRlcHJlc3NlZCBhY2NvdW50YW50 LiA6KQ0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206IGxlZGJhdC1ib3Vu Y2VzQGlldGYub3JnIDxsZWRiYXQtYm91bmNlc0BpZXRmLm9yZz4NClRvOiBCZXJuYXJkIEFib2Jh IDxiZXJuYXJkX2Fib2JhQGhvdG1haWwuY29tPg0KQ2M6IGxlZGJhdEBpZXRmLm9yZyA8bGVkYmF0 QGlldGYub3JnPg0KU2VudDogVHVlIEF1ZyAwNCAwNzo1NDowMiAyMDA5DQpTdWJqZWN0OiBSZTog W2xlZGJhdF0gRHJhZnQgbWludXRlcyBvZiB0aGUgTEVEQkFUIFdHIG1lZXRpbmcgYXQgSUVURiA3 NQ0KDQpTbWFsbCBmaXggLSB3aGljaCBnYXZlIG1lIGEgZ29vZCBsYXVnaDoNCg0KPiBNYWMgSXZl c3M6IG1hZGUgcG9pbnQgaW4gSUNDUkcsIE1VTFRJVENQLCBnYXZlIHVwcGVyIGxpbWl0IG9mIDYg YmFzZWQgb24NCj4gc29tZSBkYXRhIGZyb20gaW5mb2NvbSBwYXBlci4gIHRoaW5rIGNvdWxkIGJl IHVzZWQgZm9yIHNvbWUgb2YgdGhlc2UsIHRoaXMNCj4gZ2l2ZXMgYSByb3VnaCB2aWV3Lg0KDQpU aGlzIGR1YmlvdXMgIk1hYyBJdmVzcyIgc2VlbXMgdG8gYmUgbWUsIE1pY2hhZWwgV2Vsemw7DQph bmQgSSB0YWxrZWQgYWJvdXQgTXVsVEZSQywgbm90ICJNVUxUSVRDUCIuDQoNCk1hYyBJdmVzcywg aGVoZWhlICAgOi0pICAgSSBsaWtlIHRoYXQgbmFtZS4gTWF5YmUgSSBzaG91bGQNCnN0YXJ0IHVz aW5nIGl0IGFzIGEgcHNldWRvbnltPyBJIGhhdmUgdG8gc2F5LCBpdCBzb3VuZHMNCmNvb2xlciB0 byBtZSB0aGFuIG15IHJlYWwgbmFtZQ0KDQpjaGVlcnMsDQpNaWNoYWVsDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmxlZGJhdCBtYWlsaW5nIGxp c3QNCmxlZGJhdEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9sZWRiYXQNCg== From michawe@ulrik.uio.no Tue Aug 4 06:15:54 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAC4C3A68BB for ; Tue, 4 Aug 2009 06:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hp20+UyCn+xZ for ; Tue, 4 Aug 2009 06:15:54 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by core3.amsl.com (Postfix) with ESMTP id 0D6343A67B4 for ; Tue, 4 Aug 2009 06:15:54 -0700 (PDT) Received: from mail-mx5.uio.no ([129.240.10.46]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from ) id 1MYJqB-0002X6-Pd; Tue, 04 Aug 2009 15:14:07 +0200 Received: from w3prod-wm01.uio.no ([129.240.4.214] helo=webmail.uio.no) by mail-mx5.uio.no with esmtpsa (TLSv1:AES256-SHA:256) user michawe (Exim 4.69) (envelope-from ) id 1MYJqB-0004Xr-8N; Tue, 04 Aug 2009 15:14:07 +0200 Received: from 84.208.169.19 (SquirrelMail authenticated user michawe) by webmail.uio.no with HTTP; Tue, 4 Aug 2009 15:14:07 +0200 Message-ID: In-Reply-To: References: Date: Tue, 4 Aug 2009 15:14:07 +0200 From: michawe@ifi.uio.no To: "Woundy, Richard" User-Agent: SquirrelMail/1.4.19 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 8 sum msgs/h 3 total rcpts 2413 max rcpts/h 33 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: C2D012DE966E395D9F468A9AC4BB2D2D7D86C56A X-UiO-SPAM-Test: remote_host: 129.240.4.214 spam_score: -49 maxlevel 80 minaction 1 bait 0 mail/h: 69 total 1539969 max/h 678 blacklist 0 greylist 1 ratelimit 0 Cc: bernard_aboba@hotmail.com, ledbat@ietf.org Subject: Re: [ledbat] Draft minutes of the LEDBAT WG meeting at IETF 75 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 13:15:54 -0000 > Michael, that's much cooler than my pseudonym from the minutes: > >>Rich Moody, Comcast: any measurements to confirm this behavior? > > Mac Ivess sounds like an international spy, but Rich Moody sounds like a > depressed accountant. :) Haha... either way, we make the LEDBAT crowd more colorful, don't we? :-) cheers Mac :-) From bernard_aboba@hotmail.com Tue Aug 4 11:28:16 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5B9D3A68C9 for ; Tue, 4 Aug 2009 11:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.528 X-Spam-Level: X-Spam-Status: No, score=-1.528 tagged_above=-999 required=5 tests=[AWL=1.070, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoySalhOTUmO for ; Tue, 4 Aug 2009 11:28:13 -0700 (PDT) Received: from blu0-omc4-s32.blu0.hotmail.com (blu0-omc4-s32.blu0.hotmail.com [65.55.111.171]) by core3.amsl.com (Postfix) with ESMTP id 8DDF93A67D3 for ; Tue, 4 Aug 2009 11:28:13 -0700 (PDT) Received: from BLU137-W29 ([65.55.111.136]) by blu0-omc4-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 11:28:15 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_8a8ea34f-cde0-43f0-9967-31b147e28524_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: , Date: Tue, 4 Aug 2009 11:28:15 -0700 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 04 Aug 2009 18:28:15.0740 (UTC) FILETIME=[550433C0:01CA1531] Cc: ledbat@ietf.org Subject: [ledbat] Draft minutes of the LEDBAT WG meeting at IETF 75, Take Two X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 18:28:16 -0000 --_8a8ea34f-cde0-43f0-9967-31b147e28524_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Apologies.=20 Here is a cleaned up version (found some other issues=2C too).=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D LEDBAT WG Meeting IETF 75 Stockholm=2C Sweden Wednesday=2C July 29=2C 2009 13:00 - 15:00 Congresshall B =20 Chairs: S. Shalunov M. Sridharan B. Aboba (acting) =20 Preliminaries (10 minutes) =20 Note well Blue Sheets Minute Takers (Matthew J Zekauskas=2C Al Morton) Jabber Scribe Agenda bashing Agenda Bash Iljitsch van Beijnum would like to get feedack from folks here=2C on the ap= propriate size of buffers in home gateways. See homegate@ietf.org=2C tsvar= ea discussion ongoing. Document Status No current WG documents. Three documents under consideration for adoption = as WG work items at this meeting. =20 Documents Under Consideration for Adoption as a WG Work Item (80 minutes) 13:10 - 13:40 Low Extra Delay Background Transport (LEDBAT)=2C S. Shalunov= (30 minutes) http://tools.ietf.org/id/draft-shalunov-ledbat-congestion Doc hasn't changed from last time=2C but there was discussion on mailing li= st that we want to address. First=2C what are the goals? To saturate the = network=2C but keep delay low. Yielding to TCP and adding little extra dela= y are consequences of this=2C but we state them separately. Stas gives an overview of the congestion control goals=2C some features in = Pseudo-code. Receiver just keeps telling sender measured delay Sender is more complex. keeps delay low by measuring and reacting=2C notion of target delay. controller is a proportional-integral-derivative (PID) controller as safety measure=2C on loss=2C halve window. Question: what is the framing? UDP? TCP? Answer: The congestion control mechanism is independent of framing.=20 In an early draft of the charter=2C UDP framing was specified. It is not i= n the current charter. UDP is the most expedient way to deploy LEDBAT=2C b= ut it could work over TCP as a modification (though timestamps would be req= uired). Question: Can it work on top of the TCP control loop? Answer: Don't know=2C doesn't seem like a direct application=2C but not pa= rt of the WG charter. Could be a DCCP CCID=2C or SCTP modification/option= (timestamps required). Lars: We can discuss framing after the algorithm has stabilized and people = have played with it (document is slated for Experimental). Once we have implementation experience=2C we will take it f= rom there. Late-comer's advantage (or first mover's advantage): Consider (general prob w/delay based congestion control=2C discussed w with= respect to TCP Vegas=2C fast.): Latecomer could be deceived by outstanding queue=2C think base delay is hig= her than it is. The latecomer can't look inside the queue and see packets= =2C it only measures the delay. If have you have a stack of latecomers=2C = since they underestimate queue size=2C they could starve out the first move= rs.=20 When a sender experiences starvation=2C their estimated queue size is large= r=2C and they don't put traffic on the bottleneck=2C so the queue size will drop=2C and the latecomers will get a better baselin= e measurement. As a result=2C the latecomers queue size estimate will incr= ease and they will decrease their sending rate. So we think that the late = mover advantage will be short-lived. Such an advantage can be observed in = a simulator=2C but not in the wild=2C because in a simulator it is easy to = get phase-locked packets. In real networks you have more jitter=2C such as= disk seeks=2C which introduces randomness. More randomness increases the = probability of extreme conditions (e.g. minimum estimate of baseline delay)= . Perhaps the answer might be different for a huge number of flows. a high= er degree of statistical multiplexing. But with a few hundred flows=2C di= ps will show up regularly. Rich Woundy=2C Comcast: any measurements to confirm this behavior? Stas: fairness seems to be preserved. No studies showing measurements in= the wild. Lars: The question asked for an Experimental status is: "Will this be sa= fe on the Internet?" However=2C the longer-term question is whether this will be effective in reducing Queue size. Rich's 2nd Question: any hardware dependencies? If we move to solid stat= e storage instead of hard drives=2C so that seek times decrease=2C do the dips go away? Stas: Operating systems schedulers still introduce jitter in user space= =2C no way around that.=20 Matthew J Zekauskas: you can see this kind of RATE dip on Internet traffi= c today. Stas: You select the target=2C such that multiplication by the number of = flows works. You don't multiply the Target by the number of flows. All fl= ows target the same delay=2C whether there is one flow or fifteen. Rich again: do all apps have to use the same queuing delay target? If they= pick different queuing delay targets=2C does that work? Fairness by random redistribution The current draft does not contain this discussion=2C this will be fixed. How do multiple flows end up sharing the queue and why? As a thought experiment: suppose we want as a design goal to redistribute = a bit of capacity from connections randomly=2C while keeping same total tar= get link capacity. It is intuitively clear=2C and can be easily shown rigo= rously=2C that this could be accomplished by introducing randomness in meas= urement. Instead of using the measured delay=2C add a random quantity to i= t=2C which doesn't have to be large.=20 Whatever we need to redistribute=2C say 10 percent of RTT. Error needs to b= e a fraction of the target that's equal to # packets in RTT/10 in that case= . This is a very small fraction. If there are few packets in RTT and the t= arget is 25ms queuing delay=2C we are talking about sub-ms errors. So the question is whether randomness is there=2C such as in phase of arri= val of serialization with respect to the prevous packet. This is the same = randomness that causes dips to appear (and evens out the estimates of base = delay). lars: related work=2C RFC 5148=2C MANET. talks about jittering timers in r= outing protocols for different purpose=2C but effect is the same. Parameter Values Choice of parm values is a little more interesting. Two parameters here: GAIN and TARGET. All values on the slide are "not insane". For various definitions of "work"=2C all work. We can go further beyond these ranges. But how do we choose? Choice of GAIN is more arbitrary than choice of TARGET. GAIN: how fast do you converge=2C how stable is it. large value of GAIN ->= fast convergence=2C small value ->stable. 1 MSS/RTT and 10 MSS/RTT are both conservative. 1 has interesting property: if delay measurement is completely broken=2C an= d zero queuing delay is always measured=2C this replicates the ramp up of a= single TCP flow. This is why the value 1 was chosen originally=2C since w= e know that if we ramp up as with a single TCP flow=2C the world doesn't en= d. TARGET: is less arbitrary. There is a wide range of potential values that = are all sane. The numbers in the draft work=2C but aren't magic.=20 Higher target values are more robust: you get a smaller relative error for = any absolute error Lower target values add less delay=3B clearly there are diminishing return= s. Going from 1 sec to 0.5 sec queueing delays=2C is a huge difference for int= eractive users Going from 2 ms to 1ms queueing delay makes no difference whatsoever. 1ms is way too low=2C it is not a value that wold work=2C so that is just a= n example. Human reaction/perception threshold seems like a useful reference. Add or subtract typical RTT=2C don't add much of a disservice. Unless you are a pro gamer=2C you probably can't notice a difference of 25m= s in ping time. Why is 25ms there? Could we make it 10 or 50ms? Yes. Ted Hardie: thank you for not having magic numbers in your head. For human= perception in applications it is rarely a single flow that is taken into a= ccount before presenting to the end user. This is true for large video flo= ws=2C but for other applications=2C a combination of multiple things typica= lly will cause UI actions to appears. Hundreds of different web sites can = be required to render a single web page in extreme cases. Stas: another useful benchmark=2C not on the slide=2C is the speed of ligh= t limit on RTT=2C which is not a very large fraction of Internet delay.=20 Lars: want to disagree with Ted a bit. If directly connected to server=2C = and add this=2C making that server look 25ms away=2C is OK. 100 to 125ms i= s probably ok. We are not multiplying by the number of flows. Sean Doran: Let me pile on Ted. Are the magic numbers for humans? For au= dio=2C less than 70ms is useless. Ted: I disagree with Lars. In the case of a web page=2C you must go and fe= tch the links to render the page=2C and that might involve redirects to oth= er sites. Each additional 25ms delay can start to add up to a long renderi= ng time=2C which is perceptible by the user. We could be talking about 30 = RTT=2C which is not small. Lars: consider if we are in TCP slow start=2C with each RTT that might be l= onger. If we move the server 25ms further away from you=2C in many use cas= es=2C it will not matter=2C but there are some cases where it does: NFS. = Think of this as adding 3000km physical distance. For some applications tha= t is a big deal. Bruce Lowekamp: multiply the target by # flows. Does that assume that ther= e is a single bottleneck for all flows=2C or all have same destination? Stas: We are not assuming that. A single bottleneck is the typical case=2C= but if not=2C there is no multiplicative effect.=20 POLL: Adopt this a WG Item - 18 for adoption=2C none against. Consensus to be verified on the list. 13:40 - 14:10 LEDBAT Practices and Recommendations=2C R. Penno (30 minutes) http://tools.ietf.org/id/draft-penno-ledbat-app-practices-recommendations R. Penno is present in Stockholm but is ill and so cannot present. We will= go over the slides from IETF 74 again. The document has not been revised = since IETF 74. Stuart Cheshire: it is not clear that multiple parallel connections result = in higher throughput. I think that is a common fallacy=2C particularly on = lossy networks. If there is not enough data to trigger fast retransmit=2C = the whole thing slows down. Stas: As a general question=2C I'd like to hear the WG opinion on how much= this draft should describe practices=2C and how much it should make recomm= endations. In other words=2C do we need a better survey=2C or better guid= ance? Lars: when we wrote the charter=2C we wanted recommendations. We saw confu= sion out there. Stuart just illustrated once such issue. So having the IE= TF comment on this would be useful. Stas: Personally I think the document doesn't contain enugh recommendations= =2C but just collects evidence. We stil have to work on recommendations. Bob Briscoe: To come back to Stuart's point: 1. Educate and explain.=20 2. Recommendations may be difficult.=20 Stuart: multiple connections get bad performance=2C if each only has a few = packets and also if they are not using full size packets=2C then packing in= stream. Bob Briscoe: Oh=2C I misheard. I agree! Stas: if one connection gets all the throughput you should be getting=2C mo= re connections will not help you. Stuart: more connections does help when parallel connections get a bigger p= art of congested link. But my sense is those cases are fairly rare. When = Mosaic did it=2C we only had HTTP 1.0 and could not pipeline GETs. Now a d= ays=2C you can send 16 GET Requests over a single TCP connection=2C which i= s much faster than opening 16 connections=2C each with one GET. Michael Welzl: made point in ICCRG=2C MulTFRC=2C gave upper limit of 6 base= d on some data from INFOCOM paper. Think could be used for some of these= =2C this gives a rough view. Stas: Les Cottrell from SLAC did some measurements. Where connections were= window-limited mostly=2C very clear that dropoff past certain point. Star= t losing perf=2C even when trying to saturate link with connections. Get p= ast 10-20 connections and performance goes down. These are somewhat simila= r. Bob Briscoe: this depends on if you have a shared link or a self-congested = link. Self-congested=2C won't=3B shared=2C may. Stuart: one quick final comment=2C given that we are designing protocols th= at everyone uses. If one person is greedy=2C they get a bigger share. If = everyone is greedy=2C we're back to square one=2C but we're more inefficien= t. Stas: It is clear that in the doc=2C trying to be greedy gets more out of a= congested bottleneck=2C but that is not a good reason to use multiple conn= ections. Only classic product that opens multiple connections to get bigge= r share=2C is download mgr. Bob Briscoe: We can't tell intent at build time=3B we don't know if we have= a shared link or a self-congested link. No matter what the intent is=2C i= t might get misused in another situation. To reinforce Stuart: when we sta= rt an arms race=2C TCP squares the amount of congestion. If everyone puts = in 2 more=2C we get 4 times. 10 more=2C 100 times=2C and then "congestive = collapse". Richard Woundy=2C Comcast: I have a more fundamental question about this do= cument. Is it under active authorship? Are the authors continuing? They = didn't update the document=2C and they aren't here to present it. There is= clearly a lot of work to do. Stas: I don't have an update on the status. If it turns out that we need m= ore contributors or another editor=2C it is easier to do if it is a WG docu= ment under IETF change control. The WG can't find an editor for a non-WG d= ocument. Lars: since there is no WG work item yet in this area=2C if someone wrote a= document that the WG liked better=2C that would move forward. If it is a = WG work item=2C we could talk about replacing the editor.=20 Stas: We did talk to the editor and he wanted it to become a WG work item. = He is in Stockholm=2C but has fallen ill.=20 Lars: that explains why he is not presenting=2C but not why there is no upd= ate. I hate to step on somebody's toes=2C but I'm hesitant if there is a la= ck of editing cycles and the document is not a WG work item. This is a sit= uation where we frequently run into problems. Bernard: Who is interested in working on this document and contributing to= it? 2 folks raise their hands (Vijay and Richard Woundy). Stas: This shall not go unpunished. Who thinks this document should be accepted as a WG work item? Zero hands. Who thinks it should not be accepted? Two hands. Vijay: Since IETF 74=2C there has been no update=2C and it needed more wor= k.=20 Lars: Let's get a sense of how to move forward. If the document were to b= e updated a few times=2C would people think it could be ready=2C or will th= e document never be ready? Who thinks it would be ready if worked on some more? 11 people raise their hands. Who thinks that no matter how much effort goes into it=2C something is fund= amentally wrong? Zero hands raised. Clear message: get an active editor and put in cycles. =20 14:10 - 14:30 A Survey of Lower-than-Best Effort Transport Protocols=2C M. = Welzl (20 minutes) http://tools.ietf.org/html/draft-welzl-ledbat-survey This document is a literature review=2C to help us avoid reinventing the wh= eel. The document looks at delay-based congestion algorithms=2C as well as= application layer mechanisms. delay based algorithms TCP Vegas. not designed to be lower than best efforts (LBE). But nice= example=2C LBE in presence of Reno=2C but better if it is the only one.=20 Others based on Vegas=2C but designed for LBE: TCP Nice=2C TCP-LP non-delay based Also designed to give way=2C though growing less than TCP. 4CP=2C uses virtual window to limit congestion window earlier MulTFRC.=20 0.1 weight. 10x less agressive. But requires queue growth=2C reacts= only to losses. app layer approaches. so far=2C rcv window tuning. Some quite sophisticated ones see SIGMETRICS 04 paper. claim: could work as well as transport-layer scheme Bernard: This document is under consideration for adoption as a WG work it= em. Who wants to see it adopted? Lars: This would be published as Informational. 18 hands. Who doesn't want to see it adopted? No hands. Consensus to be verified on the list. =20 =3D=3D=3D=3D 5 minute Item - Home Gate Iljitsch van Beijnum Bar BOF Monday on home gateways: HOMEGATE. There is no charter=2C all is u= p in the air.=20 How much buffering should be in Home Gateways? Wants people to send their info and thoughts about buffering and queueing s= trategies. join homegate@ietf.org or send feedback to Iljitsch: www.ietf.org/mailman/listinfo/homegate Stas - don't do things in HOMEGATE that make LEDBAT's job harder. Very sma= ll buffer would make congestion control more difficult. Prefer the "Do no = harm" criteria for recommendations. Bob Briscoe: Weighted Fair Queuing isn't designed for Homegateways -- don't= isolate the apps from each other. Mark Handley - very small buffers on GigE links with high stat mux Richard Woundy - 10 packets may not be enough buffer=2C 150ms to 200ms wort= h <100 but more than 10 packets... Dave Oran - the box that controls L2 state (e.g. 802.11 power save bufferin= g) has no interaction with the device L3 queuing. Think Cable Modem: "Comcast=2C it's our fault." Back to Richard's comment:= need longer queue sometimes. Next Steps and Wrapup (30 minutes) 14:30 - 15:00 Chairs & Area Directors (30 minutes) Nothing to Discuss - all votes were Unanimous. --_8a8ea34f-cde0-43f0-9967-31b147e28524_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Apologies.

Here is a cleaned up version (found some other issues=2C= too).

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

LEDBAT WG Meeting
IETF 75
Stockholm=2C Sweden

Wednesda= y=2C July 29=2C 2009
13:00 - 15:00
Congresshall B
 =3B =3B=  =3B =3B =3B =3B =3B =3B
Chairs: =3B S. Sha= lunov
 =3B =3B =3B =3B =3B =3B =3B =3B M= . Sridharan
 =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B B. Aboba (acting)
 =3B =3B =3B =3B =3B =3B&= nbsp=3B =3B
Preliminaries (10 minutes)
 =3B =3B =3B&= nbsp=3B =3B =3B =3B =3B
 =3B =3B =3B = =3B =3B =3B =3B =3B Note well
 =3B =3B =3B&n= bsp=3B =3B =3B =3B =3B Blue Sheets
 =3B =3B = =3B =3B =3B =3B =3B =3B Minute Takers (Matthew J Zekaus= kas=2C Al Morton)
 =3B =3B =3B =3B =3B =3B = =3B =3B Jabber Scribe
 =3B =3B =3B =3B =3B = =3B =3B =3B Agenda bashing

Agenda Bash

Iljitsch van B= eijnum would like to get feedack from folks here=2C on the appropriate size= of buffers in home gateways. =3B See homegate@ietf.org=2C tsvarea disc= ussion ongoing.

Document Status

No current WG documents. = =3B Three documents under consideration for adoption as WG work items at th= is meeting.
 =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B
Documents Under Consideration for Adoption as a WG Work Item (80 m= inutes)

13:10 - 13:40 Low Extra Delay Background =3B Transport (= LEDBAT)=2C S. Shalunov (30 minutes)
http://tools.ietf.org/id/draft-shalu= nov-ledbat-congestion

Doc hasn't changed from last time=2C but there= was discussion on mailing list that we want to address. =3B First=2C w= hat are the goals? =3B To saturate the network=2C but keep delay low. Y= ielding to TCP and adding little extra delay are consequences of this=2C bu= t we state them separately.

Stas gives an overview of the congestion= control goals=2C some features in Pseudo-code.
Receiver just keeps tell= ing sender measured delay
Sender is more complex.
 =3B keeps dela= y low by measuring and reacting=2C notion of target delay.
 =3B cont= roller is a proportional-integral-derivative (PID) controller
 =3B a= s safety measure=2C on loss=2C halve window.

Question: =3B what = is the framing? =3B UDP? =3B TCP?
Answer: =3B The congestion= control mechanism is independent of framing.
In an early draft of the = charter=2C UDP framing was specified. =3B It is not in the current char= ter. =3B UDP is the most expedient way to deploy LEDBAT=2C but it could= work over TCP as a modification (though timestamps would be required).
= Question: =3B Can it work on top of the TCP control loop?
Answer:&nb= sp=3B Don't know=2C doesn't seem like a direct application=2C but not part = of the WG charter. =3B =3B Could be a DCCP CCID=2C or SCTP modifica= tion/option (timestamps required).
Lars: We can discuss framing after th= e algorithm has stabilized and people have played with it (document is slat= ed for
Experimental). =3B Once we have implementation experience=2C = we will take it from there.

Late-comer's advantage (or first mover's= advantage):

Consider (general prob w/delay based congestion control= =2C discussed w with respect to TCP Vegas=2C fast.):
Latecomer could be = deceived by outstanding queue=2C think base delay is higher than it is.&nbs= p=3B =3B The latecomer can't look inside the queue and see packets=2C i= t only measures the delay. =3B If have you have a stack of latecomers= =2C since they underestimate queue size=2C they could starve out the first = movers.

When a sender experiences starvation=2C their estimated que= ue size is larger=2C and they don't put traffic on the bottleneck=2C
so = the queue size will drop=2C and the latecomers will get a better baseline m= easurement. =3B As a result=2C the latecomers queue size estimate will = increase and they will decrease their sending rate. =3B So we think tha= t the late mover advantage will be short-lived. =3B Such an advantage c= an be observed in a simulator=2C but not in the wild=2C because in a simula= tor it is easy to get phase-locked packets. =3B In real networks you ha= ve more jitter=2C such as disk seeks=2C which introduces randomness. = =3B More randomness increases the probability of extreme conditions (e.g. m= inimum estimate of baseline delay). Perhaps the answer might be different f= or a huge number of flows. =3B a higher degree of statistical multiplex= ing. =3B But with a few hundred flows=2C =3B dips will show up regu= larly.

 =3B Rich Woundy=2C Comcast: any measurements to confirm = this behavior?
 =3B Stas: fairness seems to be preserved. =3B No= studies showing measurements in the wild.
 =3B Lars: =3B The qu= estion asked for an Experimental status is: "Will this be safe on the Inter= net?" =3B However=2C the longer-term
 =3B =3B =3B = =3B =3B =3B =3B =3B question is whether this will be effect= ive in reducing Queue size.

 =3B Rich's 2nd Question: any hardwa= re dependencies? =3B If we move to solid state storage instead of hard = drives=2C so that seek
 =3B =3B =3B =3B =3B =3B = times decrease=2C do the dips go away?
 =3B Stas: =3B Operating = systems schedulers still introduce jitter in user space=2C no way around th= at.
 =3B Matthew J Zekauskas: you can see this kind of RATE dip on = Internet traffic today.

 =3BStas: =3B You select the target= =2C such that multiplication by the number of flows works. =3B You don'= t multiply the Target by the number of flows. =3B All flows target the = same delay=2C whether there is one flow or fifteen.
 =3BRich again: = do all apps have to use the same queuing delay target? If they pick differe= nt queuing delay targets=2C does that work?

Fairness by random redis= tribution

The current draft does not contain this discussion=2C this= will be fixed.
How do multiple flows end up sharing the queue and why?<= br>
As a thought experiment: =3B suppose we want as a design goal to= redistribute a bit of capacity from connections randomly=2C while keeping = same total target link capacity. =3B It is intuitively clear=2C and can= be easily shown rigorously=2C that this could be accomplished by introduci= ng randomness in measurement. =3B Instead of using the measured delay= =2C add a random quantity to it=2C which doesn't have to be large.

= Whatever we need to redistribute=2C say 10 percent of RTT. Error needs to b= e a fraction of the target that's equal to # packets in RTT/10 in that case= . =3B This is a very small fraction. If there are few packets in RTT an= d the target is 25ms queuing delay=2C we are talking about sub-ms errors.
So the question is whether randomness is there=2C such as in =3B = phase of arrival of serialization with respect to the prevous packet. = =3B This is the same randomness that causes dips to appear (and evens out t= he estimates of base delay).

lars: related work=2C RFC 5148=2C MANET= . =3B talks about jittering timers in routing protocols for different p= urpose=2C but effect is the same.

Parameter Values

Choice of = parm values is a little more interesting.
Two parameters here: GAIN and = TARGET.
All values on the slide are "not insane".
For various definit= ions of "work"=2C all work.
We can go further beyond these ranges. = =3B But how do we choose?

Choice of GAIN is more arbitrary than choi= ce of TARGET.
GAIN: how fast do you converge=2C how stable is it. = =3B large value of GAIN ->=3Bfast convergence=2C small value ->=3Bstabl= e.
1 MSS/RTT and 10 MSS/RTT are both conservative.
1 has interesting = property: if delay measurement is completely broken=2C and zero queuing del= ay is always measured=2C this replicates the ramp up of a single TCP flow.&= nbsp=3B This is why the value 1 was chosen originally=2C since we know that= if we ramp up as with a single TCP flow=2C the world doesn't end.

T= ARGET: is less arbitrary. =3B There is a wide range of potential values= that are all sane. =3B The numbers in the draft work=2C but aren't mag= ic.

Higher target values are more robust: you get a smaller relativ= e error for any absolute error
Lower target values add less delay=3B&nbs= p=3B clearly there are diminishing returns.
Going from 1 sec to 0.5 sec = queueing delays=2C is a huge difference for interactive users
Going from= 2 ms to 1ms queueing delay makes no difference whatsoever.
1ms is way t= oo low=2C it is not a value that wold work=2C so that is just an example.
Human reaction/perception threshold seems like a useful reference.Add or subtract typical RTT=2C don't add much of a disservice.
Unless y= ou are a pro gamer=2C you probably can't notice a difference of 25ms in pin= g time.
Why is 25ms there? =3B Could we make it 10 or 50ms? =3B = Yes.

Ted Hardie: thank you for not having magic numbers in your head= . =3B For human perception in applications it is rarely a single flow t= hat is taken into account before presenting to the end user. =3B This i= s true for large video flows=2C but for other applications=2C a combination= of multiple things typically will cause UI actions to appears. =3B Hun= dreds of different web sites can be required to render a single web page in= extreme cases.

Stas: =3B another useful benchmark=2C not on the= slide=2C is the speed of light limit on RTT=2C which is not a very large f= raction of Internet delay.

Lars: want to disagree with Ted a bit.&n= bsp=3B If directly connected to server=2C and add this=2C making that serve= r look 25ms away=2C is OK. =3B 100 to 125ms is probably ok. =3B We = are not multiplying by the number of flows.

Sean Doran: =3B Let = me pile on Ted. =3B Are the magic numbers for humans? =3B For audio= =2C less than 70ms is useless.

Ted: I disagree with Lars. =3B In= the case of a web page=2C you must go and fetch the links to render the pa= ge=2C and that might involve redirects to other sites. =3B Each additio= nal 25ms delay can start to add up to a long rendering time=2C which is per= ceptible by the user. =3B We could be talking about 30 RTT=2C which is = not small.

Lars: consider if we are in TCP slow start=2C with each R= TT that might be longer. =3B If we move the server 25ms further away fr= om you=2C in many use cases=2C it will not matter=2C but there are some cas= es where it does: =3B NFS. =3B Think of this as adding 3000km physi= cal distance. For some applications that is a big deal.

Bruce Loweka= mp: multiply the target by # flows. =3B Does that assume that there is = a single bottleneck for all flows=2C or all have same destination?

S= tas: We are not assuming that. =3B A single bottleneck is the typical c= ase=2C but if not=2C there is no multiplicative effect.

POLL: = =3B Adopt this a WG Item =3B - 18 for adoption=2C none against.
Cons= ensus to be verified on the list.

13:40 - 14:10 LEDBAT Practices and= Recommendations=2C R. Penno (30 minutes)
http://tools.ietf.org/id/draft= -penno-ledbat-app-practices-recommendations

R. Penno is present in S= tockholm but is ill and so cannot present. =3B We will go over the slid= es from IETF 74 again. =3B The document has not been revised since IETF= 74.

Stuart Cheshire: it is not clear that multiple parallel connect= ions result in higher throughput. =3B I think that is a common fallacy= =2C particularly on lossy networks. =3B If there is not enough data to = trigger fast retransmit=2C the whole thing slows down.

Stas: =3B= As a general question=2C I'd like to hear the WG opinion on how much this = draft should describe practices=2C and how much it should make recommendati= ons. =3B =3B In other words=2C do we need a better survey=2C or bet= ter guidance?

Lars: when we wrote the charter=2C we wanted recommend= ations. =3B We saw confusion out there. =3B Stuart just illustrated= once such issue. =3B So having the IETF comment on this would be usefu= l.

Stas: Personally I think the document doesn't contain enugh recom= mendations=2C but just collects evidence. =3B We stil have to work on r= ecommendations.

Bob Briscoe: To come back to Stuart's point:
&nbs= p=3B 1. =3B Educate and explain.
 =3B 2. =3B Recommendation= s may be difficult.

Stuart: multiple connections get bad performanc= e=2C if each only has a few packets and also if they are not using full siz= e packets=2C then packing in stream.

Bob Briscoe: =3B Oh=2C I mi= sheard. =3B I agree!

Stas: if one connection gets all the throug= hput you should be getting=2C more connections will not help you.

St= uart: more connections does help when parallel connections get a bigger par= t of congested link. =3B But my sense is those cases are fairly rare.&n= bsp=3B When Mosaic did it=2C we only had HTTP 1.0 and could not pipeline GE= Ts. =3B Now a days=2C you can send 16 GET Requests over a single TCP co= nnection=2C which is much faster than opening 16 connections=2C each with o= ne GET.

Michael Welzl: made point in ICCRG=2C MulTFRC=2C gave upper = limit of 6 based on some data from INFOCOM paper. =3B Think could be us= ed for some of these=2C this gives a rough view.

Stas: Les Cottrell = from SLAC did some measurements. =3B Where connections were window-limi= ted mostly=2C very clear that dropoff past certain point. =3B Start los= ing perf=2C even when trying to saturate link with connections. =3B Get= past 10-20 connections and performance goes down. =3B These are somewh= at similar.

Bob Briscoe: this depends on if you have a shared link o= r a self-congested link. Self-congested=2C won't=3B shared=2C may.

S= tuart: one quick final comment=2C given that we are designing protocols tha= t everyone uses. =3B If one person is greedy=2C they get a bigger share= . =3B If everyone is greedy=2C we're back to square one=2C but we're mo= re inefficient.

Stas: It is clear that in the doc=2C trying to be gr= eedy gets more out of a congested bottleneck=2C but that is not a good reas= on to use multiple connections. =3B Only classic product that opens mul= tiple connections to get bigger share=2C is download mgr.

Bob Brisco= e: We can't tell intent at build time=3B we don't know if we have a shared = link or a self-congested link. =3B No matter what the intent is=2C it m= ight get misused in another situation. =3B To reinforce Stuart: when we= start an arms race=2C TCP squares the amount of congestion. =3B If eve= ryone puts in 2 more=2C we get 4 times. =3B 10 more=2C 100 times=2C and= then "congestive collapse".

Richard Woundy=2C Comcast: I have a mor= e fundamental question about this document. =3B Is it under active auth= orship? =3B Are the authors continuing? =3B They didn't update the = document=2C and they aren't here to present it. =3B There is clearly a = lot of work to do.

Stas: I don't have an update on the status. = =3B If it turns out that we need more contributors or another editor=2C it = is easier to do if it is a WG document under IETF change control. =3B T= he WG can't find an editor for a non-WG document.

Lars: since there = is no WG work item yet in this area=2C if someone wrote a document that the= WG liked better=2C that would move forward. =3B If it is a WG work ite= m=2C we could talk about replacing the editor.

Stas: We did talk to= the editor and he wanted it to become a WG work item. =3B He is in Sto= ckholm=2C but has fallen ill.
Lars: that explains why he is not present= ing=2C but not why there is no update. I hate to step on somebody's toes=2C= but I'm hesitant if there is a lack of editing cycles and the document is = not a WG work item. =3B This is a situation where we frequently run int= o problems.

Bernard: =3B Who is interested in working on this do= cument and contributing to it?
2 folks raise their hands (Vijay and Rich= ard Woundy).
Stas: =3B This shall not go unpunished.

Who thin= ks this document should be accepted as a WG work item?
Zero hands.
Wh= o thinks it should not be accepted?
Two hands.

Vijay: =3B Sin= ce IETF 74=2C there has been no update=2C and it needed more work.
Lars= : =3B Let's get a sense of how to move forward. =3B If the document= were to be updated a few times=2C would people think it could be ready=2C = or will the document never be ready?

Who thinks it would be ready if= worked on some more?
11 people raise their hands.

Who thinks tha= t no matter how much effort goes into it=2C something is fundamentally wron= g?
Zero hands raised.

Clear message: get an active editor and put= in cycles.
 =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B
14:10 - 14:30 A Survey of Lower-than-Best Effort Transport Protoco= ls=2C M. Welzl (20 minutes)
http://tools.ietf.org/html/draft-welzl-ledba= t-survey

This document is a literature review=2C to help us avoid re= inventing the wheel. =3B The document looks at delay-based congestion a= lgorithms=2C as well as application layer mechanisms.

delay based al= gorithms
 =3B =3B =3B TCP Vegas. =3B not designed to be = lower than best efforts (LBE). =3B But nice example=2C LBE in presence = of Reno=2C but better if it is the only one.

 =3B =3B = =3B Others based on Vegas=2C but designed for LBE: TCP Nice=2C TCP-LP
non-delay based
 =3B Also designed to give way=2C though growing l= ess than TCP.
 =3B 4CP=2C uses virtual window to limit congestion wi= ndow earlier
 =3B MulTFRC.
 =3B =3B =3B =3B = =3B 0.1 weight. =3B 10x less agressive. =3B But requires queue grow= th=2C reacts only to losses.

app layer approaches.
 =3B so fa= r=2C rcv window tuning. =3B Some quite sophisticated ones
 =3B s= ee SIGMETRICS 04 paper.
 =3B =3B claim: could work as well as tr= ansport-layer scheme

Bernard: =3B This document is under conside= ration for adoption as a WG work item. =3B =3B Who wants to see it = adopted?
Lars: =3B This would be published as Informational.

= 18 hands.
Who doesn't want to see it adopted?
No hands.

Consen= sus to be verified on the list.
 =3B
=3D=3D=3D=3D
5 minute Ite= m - Home Gate
Iljitsch van Beijnum

Bar BOF Monday on home gateway= s: =3B HOMEGATE. There is no charter=2C all is up in the air.
How m= uch buffering should be in Home Gateways?
Wants people to send their inf= o and thoughts about buffering and queueing strategies.
join homegate@ie= tf.org or send feedback to Iljitsch:
www.ietf.org/mailman/listinfo/homeg= ate <=3Bhttp://www.ietf.org/mailman/listinfo/homegate>=3B

Stas -= don't do things in HOMEGATE that make LEDBAT's job harder. =3B Very sm= all buffer would make congestion control more difficult. Prefer the =3B= "Do no harm" criteria for recommendations.

Bob Briscoe: Weighted Fa= ir Queuing isn't designed for Homegateways -- don't isolate the apps from e= ach other.
Mark Handley - very small buffers on GigE links with high sta= t mux
Richard Woundy - 10 packets may not be enough buffer=2C 150ms to 2= 00ms worth <=3B100 but more than 10 packets...
Dave Oran - the box tha= t controls L2 state (e.g. 802.11 power save buffering) has no interaction w= ith the device L3 queuing.
Think Cable Modem: "Comcast=2C it's our fault= ." =3B Back to Richard's comment: need longer queue sometimes.

<= br>Next Steps and Wrapup (30 minutes)

14:30 - 15:00 Chairs &=3B A= rea Directors (30 minutes)

Nothing to Discuss - all votes were Unani= mous.


= --_8a8ea34f-cde0-43f0-9967-31b147e28524_-- From rossi.dario.g@gmail.com Fri Aug 7 10:19:38 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 359143A6910 for ; Fri, 7 Aug 2009 10:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.117 X-Spam-Level: X-Spam-Status: No, score=-0.117 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPAB1sIetReC for ; Fri, 7 Aug 2009 10:19:36 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id 9EA9E3A689E for ; Fri, 7 Aug 2009 10:19:03 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so394504fgg.18 for ; Fri, 07 Aug 2009 10:19:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Dy86GDMCN+/sa25OjglqmEG5pWYAv6klYcxT5dLoQfA=; b=Ary94c09GeBWxzzfZe0x+UEj946qQ4iV+Ebcub66gamIJxBkadVL5TPYGgFmTjkJ7t m8dC8MC+Y1ZqIJAXqMvqXrEv/anmiejJukqSYald4R4s47ZCOrvc56DVLEYLq5w8yGMg rsPPCpIM+cuSEgB5mMGgXdXE11BkXivdkuf+o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:date:x-google-sender-auth:message-id :subject:from:to:cc:content-type; b=GVL7kIM7qq2oL28sCTHzMUM93x0h/LZI30cy0ORb/9Of5dh67e5VMHjQDhtdimXmdc iPF0jceCISeSS35qAOpXk6iHs3/EzHZmLr454NsW5fDy+tc2TGp8JF13XqNT6vDJOVVs yfc76hvmEqzZ0VHIYagXM3MH8b0Y5EorUo9uk= MIME-Version: 1.0 Sender: rossi.dario.g@gmail.com Received: by 10.86.27.17 with SMTP id a17mr1108447fga.17.1249665543941; Fri, 07 Aug 2009 10:19:03 -0700 (PDT) Date: Fri, 7 Aug 2009 19:19:03 +0200 X-Google-Sender-Auth: c69bef9bb8926270 Message-ID: From: dario rossi To: ledbat@ietf.org Content-Type: multipart/alternative; boundary=000e0cd29d3ad5ae420470906e6c Cc: "claudio.testa" , Paolo Veglia Subject: Re: [ledbat] Draft minutes of the LEDBAT WG meeting at IETF 75 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dario.rossi@enst.fr List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 17:21:16 -0000 --000e0cd29d3ad5ae420470906e6c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all, this message to inform you that we've been implementing a Ledbat module for ns2, that we would like to share with the community as open source code. as the code requires a little bit of cleanup, we expect to put it on a webpage after the summer (we'll announce on the mailing list as soon as it will be ready) at the same time, we also would like to share some preliminary results which are well in line with discussions going on in the list, and that are accessible at: http://arxiv.org/abs/0908.0812 shortly, we find that late comer situations do arise; however, we also find that a simple mean to break unfair situations could be to use slow-start (as this will let the flows loose some packets, allowing the capacity to drain the queue, which in turn allows late comers to gather a good measurement of the base delay; more details in the paper) we have more activities going on, we expect to report on that after the summer period as well. Best regards, D. -- Oo Dario Rossi > Ass. Prof. ~ Telecom ParisTech http://www.enst.fr/~drossi --000e0cd29d3ad5ae420470906e6c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all,


this message to inform you that we've been impleme= nting a Ledbat module for ns2, that we would like to share with the communi= ty as open source code.

as the code requires a little bit of cleanup= , we expect to put it on a webpage after the summer (we'll announce on = the mailing list as soon as it will be ready)

at the same time, we also would like to share some preliminary results = which are well in line with discussions going on in the list, and that are = accessible at: http://arxiv.org/= abs/0908.0812

shortly, we find that late comer situations do arise; however, we also = find that a simple mean to break unfair situations could be to use slow-sta= rt (as this will let the flows loose some packets, allowing the capacity to= drain the queue, which in turn allows late comers to gather a good measure= ment of the base delay; more details in the paper)

we have more activities going on, we expect to report on that after the= summer period as well.

Best regards,
D.


--

Oo= =A0=A0 Dario Rossi
=A0 >=A0=A0=A0 Ass. Prof.
~=A0=A0=A0=A0 Teleco= m ParisTech
http://www.enst.fr/~d= rossi
--000e0cd29d3ad5ae420470906e6c-- From shalunov@bittorrent.com Fri Aug 7 11:28:13 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E65523A685F for ; Fri, 7 Aug 2009 11:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9GQGFe+hp4w for ; Fri, 7 Aug 2009 11:28:12 -0700 (PDT) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by core3.amsl.com (Postfix) with ESMTP id 2DF3E3A6946 for ; Fri, 7 Aug 2009 11:28:10 -0700 (PDT) Received: by fxm26 with SMTP id 26so1536565fxm.42 for ; Fri, 07 Aug 2009 11:28:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.113.9 with SMTP id y9mr355819fap.61.1249669690834; Fri, 07 Aug 2009 11:28:10 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Aug 2009 11:28:10 -0700 Message-ID: <6c82d1360908071128i14f4fbf1q608627957760b8b8@mail.gmail.com> From: Stanislav Shalunov To: ledbat@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [ledbat] Draft minutes of the LEDBAT WG meeting at IETF 75, Take Two X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 18:28:14 -0000 These draft minutes are now uploaded to http://www.ietf.org/proceedings/75/minutes/ledbat.txt If there are any corrections, please send them to the list. Thanks, -- Stas On Tue, Aug 4, 2009 at 11:28 AM, Bernard Aboba w= rote: > Apologies. > > Here is a cleaned up version (found some other issues, too). > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > LEDBAT WG Meeting > IETF 75 > Stockholm, Sweden > > Wednesday, July 29, 2009 > 13:00 - 15:00 > Congresshall B > > Chairs:=A0 S. Shalunov > =A0=A0=A0=A0=A0=A0=A0=A0 M. Sridharan > =A0=A0=A0=A0=A0=A0=A0=A0 B. Aboba (acting) > > Preliminaries (10 minutes) > > =A0=A0=A0=A0=A0=A0=A0=A0 Note well > =A0=A0=A0=A0=A0=A0=A0=A0 Blue Sheets > =A0=A0=A0=A0=A0=A0=A0=A0 Minute Takers (Matthew J Zekauskas, Al Morton) > =A0=A0=A0=A0=A0=A0=A0=A0 Jabber Scribe > =A0=A0=A0=A0=A0=A0=A0=A0 Agenda bashing > > Agenda Bash > > Iljitsch van Beijnum would like to get feedack from folks here, on the > appropriate size of buffers in home gateways.=A0 See homegate@ietf.org, > tsvarea discussion ongoing. > > Document Status > > No current WG documents.=A0 Three documents under consideration for adopt= ion > as WG work items at this meeting. > > Documents Under Consideration for Adoption as a WG Work Item (80 minutes) > > 13:10 - 13:40 Low Extra Delay Background=A0 Transport (LEDBAT), S. Shalun= ov > (30 minutes) > http://tools.ietf.org/id/draft-shalunov-ledbat-congestion > > Doc hasn't changed from last time, but there was discussion on mailing li= st > that we want to address.=A0 First, what are the goals?=A0 To saturate the > network, but keep delay low. Yielding to TCP and adding little extra dela= y > are consequences of this, but we state them separately. > > Stas gives an overview of the congestion control goals, some features in > Pseudo-code. > Receiver just keeps telling sender measured delay > Sender is more complex. > =A0 keeps delay low by measuring and reacting, notion of target delay. > =A0 controller is a proportional-integral-derivative (PID) controller > =A0 as safety measure, on loss, halve window. > > Question:=A0 what is the framing?=A0 UDP?=A0 TCP? > Answer:=A0 The congestion control mechanism is independent of framing. > In an early draft of the charter, UDP framing was specified.=A0 It is not= in > the current charter.=A0 UDP is the most expedient way to deploy LEDBAT, b= ut it > could work over TCP as a modification (though timestamps would be require= d). > Question:=A0 Can it work on top of the TCP control loop? > Answer:=A0 Don't know, doesn't seem like a direct application, but not pa= rt of > the WG charter.=A0=A0 Could be a DCCP CCID, or SCTP modification/option > (timestamps required). > Lars: We can discuss framing after the algorithm has stabilized and peopl= e > have played with it (document is slated for > Experimental).=A0 Once we have implementation experience, we will take it= from > there. > > Late-comer's advantage (or first mover's advantage): > > Consider (general prob w/delay based congestion control, discussed w with > respect to TCP Vegas, fast.): > Latecomer could be deceived by outstanding queue, think base delay is hig= her > than it is.=A0=A0 The latecomer can't look inside the queue and see packe= ts, it > only measures the delay.=A0 If have you have a stack of latecomers, since= they > underestimate queue size, they could starve out the first movers. > > When a sender experiences starvation, their estimated queue size is large= r, > and they don't put traffic on the bottleneck, > so the queue size will drop, and the latecomers will get a better baselin= e > measurement.=A0 As a result, the latecomers queue size estimate will incr= ease > and they will decrease their sending rate.=A0 So we think that the late m= over > advantage will be short-lived.=A0 Such an advantage can be observed in a > simulator, but not in the wild, because in a simulator it is easy to get > phase-locked packets.=A0 In real networks you have more jitter, such as d= isk > seeks, which introduces randomness.=A0 More randomness increases the > probability of extreme conditions (e.g. minimum estimate of baseline dela= y). > Perhaps the answer might be different for a huge number of flows.=A0 a hi= gher > degree of statistical multiplexing.=A0 But with a few hundred flows,=A0 d= ips > will show up regularly. > > =A0 Rich Woundy, Comcast: any measurements to confirm this behavior? > =A0 Stas: fairness seems to be preserved.=A0 No studies showing measureme= nts in > the wild. > =A0 Lars:=A0 The question asked for an Experimental status is: "Will this= be > safe on the Internet?"=A0 However, the longer-term > =A0=A0=A0=A0=A0=A0=A0=A0 question is whether this will be effective in re= ducing Queue size. > > =A0 Rich's 2nd Question: any hardware dependencies?=A0 If we move to soli= d state > storage instead of hard drives, so that seek > =A0=A0=A0=A0=A0=A0 times decrease, do the dips go away? > =A0 Stas:=A0 Operating systems schedulers still introduce jitter in user = space, > no way around that. > =A0 Matthew J Zekauskas: you can see this kind of RATE dip on Internet tr= affic > today. > > =A0Stas:=A0 You select the target, such that multiplication by the number= of > flows works.=A0 You don't multiply the Target by the number of flows.=A0 = All > flows target the same delay, whether there is one flow or fifteen. > =A0Rich again: do all apps have to use the same queuing delay target? If = they > pick different queuing delay targets, does that work? > > Fairness by random redistribution > > The current draft does not contain this discussion, this will be fixed. > How do multiple flows end up sharing the queue and why? > > As a thought experiment:=A0 suppose we want as a design goal to redistrib= ute a > bit of capacity from connections randomly, while keeping same total targe= t > link capacity.=A0 It is intuitively clear, and can be easily shown rigoro= usly, > that this could be accomplished by introducing randomness in measurement. > Instead of using the measured delay, add a random quantity to it, which > doesn't have to be large. > > Whatever we need to redistribute, say 10 percent of RTT. Error needs to b= e a > fraction of the target that's equal to # packets in RTT/10 in that case. > This is a very small fraction. If there are few packets in RTT and the > target is 25ms queuing delay, we are talking about sub-ms errors. > > So the question is whether randomness is there, such as in=A0 phase of ar= rival > of serialization with respect to the prevous packet.=A0 This is the same > randomness that causes dips to appear (and evens out the estimates of bas= e > delay). > > lars: related work, RFC 5148, MANET.=A0 talks about jittering timers in > routing protocols for different purpose, but effect is the same. > > Parameter Values > > Choice of parm values is a little more interesting. > Two parameters here: GAIN and TARGET. > All values on the slide are "not insane". > For various definitions of "work", all work. > We can go further beyond these ranges.=A0 But how do we choose? > > Choice of GAIN is more arbitrary than choice of TARGET. > GAIN: how fast do you converge, how stable is it.=A0 large value of GAIN > ->fast convergence, small value ->stable. > 1 MSS/RTT and 10 MSS/RTT are both conservative. > 1 has interesting property: if delay measurement is completely broken, an= d > zero queuing delay is always measured, this replicates the ramp up of a > single TCP flow.=A0 This is why the value 1 was chosen originally, since = we > know that if we ramp up as with a single TCP flow, the world doesn't end. > > TARGET: is less arbitrary.=A0 There is a wide range of potential values t= hat > are all sane.=A0 The numbers in the draft work, but aren't magic. > > Higher target values are more robust: you get a smaller relative error fo= r > any absolute error > Lower target values add less delay;=A0 clearly there are diminishing retu= rns. > Going from 1 sec to 0.5 sec queueing delays, is a huge difference for > interactive users > Going from 2 ms to 1ms queueing delay makes no difference whatsoever. > 1ms is way too low, it is not a value that wold work, so that is just an > example. > > Human reaction/perception threshold seems like a useful reference. > Add or subtract typical RTT, don't add much of a disservice. > Unless you are a pro gamer, you probably can't notice a difference of 25m= s > in ping time. > Why is 25ms there?=A0 Could we make it 10 or 50ms?=A0 Yes. > > Ted Hardie: thank you for not having magic numbers in your head.=A0 For h= uman > perception in applications it is rarely a single flow that is taken into > account before presenting to the end user.=A0 This is true for large vide= o > flows, but for other applications, a combination of multiple things > typically will cause UI actions to appears.=A0 Hundreds of different web = sites > can be required to render a single web page in extreme cases. > > Stas:=A0 another useful benchmark, not on the slide, is the speed of ligh= t > limit on RTT, which is not a very large fraction of Internet delay. > > Lars: want to disagree with Ted a bit.=A0 If directly connected to server= , and > add this, making that server look 25ms away, is OK.=A0 100 to 125ms is > probably ok.=A0 We are not multiplying by the number of flows. > > Sean Doran:=A0 Let me pile on Ted.=A0 Are the magic numbers for humans?= =A0 For > audio, less than 70ms is useless. > > Ted: I disagree with Lars.=A0 In the case of a web page, you must go and = fetch > the links to render the page, and that might involve redirects to other > sites.=A0 Each additional 25ms delay can start to add up to a long render= ing > time, which is perceptible by the user.=A0 We could be talking about 30 R= TT, > which is not small. > > Lars: consider if we are in TCP slow start, with each RTT that might be > longer.=A0 If we move the server 25ms further away from you, in many use > cases, it will not matter, but there are some cases where it does:=A0 NFS= . > Think of this as adding 3000km physical distance. For some applications t= hat > is a big deal. > > Bruce Lowekamp: multiply the target by # flows.=A0 Does that assume that = there > is a single bottleneck for all flows, or all have same destination? > > Stas: We are not assuming that.=A0 A single bottleneck is the typical cas= e, > but if not, there is no multiplicative effect. > > POLL:=A0 Adopt this a WG Item=A0 - 18 for adoption, none against. > Consensus to be verified on the list. > > 13:40 - 14:10 LEDBAT Practices and Recommendations, R. Penno (30 minutes) > http://tools.ietf.org/id/draft-penno-ledbat-app-practices-recommendations > > R. Penno is present in Stockholm but is ill and so cannot present.=A0 We = will > go over the slides from IETF 74 again.=A0 The document has not been revis= ed > since IETF 74. > > Stuart Cheshire: it is not clear that multiple parallel connections resul= t > in higher throughput.=A0 I think that is a common fallacy, particularly o= n > lossy networks.=A0 If there is not enough data to trigger fast retransmit= , the > whole thing slows down. > > Stas:=A0 As a general question, I'd like to hear the WG opinion on how mu= ch > this draft should describe practices, and how much it should make > recommendations.=A0=A0 In other words, do we need a better survey, or bet= ter > guidance? > > Lars: when we wrote the charter, we wanted recommendations.=A0 We saw > confusion out there.=A0 Stuart just illustrated once such issue.=A0 So ha= ving > the IETF comment on this would be useful. > > Stas: Personally I think the document doesn't contain enugh recommendatio= ns, > but just collects evidence.=A0 We stil have to work on recommendations. > > Bob Briscoe: To come back to Stuart's point: > =A0 1.=A0 Educate and explain. > =A0 2.=A0 Recommendations may be difficult. > > Stuart: multiple connections get bad performance, if each only has a few > packets and also if they are not using full size packets, then packing in > stream. > > Bob Briscoe:=A0 Oh, I misheard.=A0 I agree! > > Stas: if one connection gets all the throughput you should be getting, mo= re > connections will not help you. > > Stuart: more connections does help when parallel connections get a bigger > part of congested link.=A0 But my sense is those cases are fairly rare.= =A0 When > Mosaic did it, we only had HTTP 1.0 and could not pipeline GETs.=A0 Now a > days, you can send 16 GET Requests over a single TCP connection, which is > much faster than opening 16 connections, each with one GET. > > Michael Welzl: made point in ICCRG, MulTFRC, gave upper limit of 6 based = on > some data from INFOCOM paper.=A0 Think could be used for some of these, t= his > gives a rough view. > > Stas: Les Cottrell from SLAC did some measurements.=A0 Where connections = were > window-limited mostly, very clear that dropoff past certain point.=A0 Sta= rt > losing perf, even when trying to saturate link with connections.=A0 Get p= ast > 10-20 connections and performance goes down.=A0 These are somewhat simila= r. > > Bob Briscoe: this depends on if you have a shared link or a self-congeste= d > link. Self-congested, won't; shared, may. > > Stuart: one quick final comment, given that we are designing protocols th= at > everyone uses.=A0 If one person is greedy, they get a bigger share.=A0 If > everyone is greedy, we're back to square one, but we're more inefficient. > > Stas: It is clear that in the doc, trying to be greedy gets more out of a > congested bottleneck, but that is not a good reason to use multiple > connections.=A0 Only classic product that opens multiple connections to g= et > bigger share, is download mgr. > > Bob Briscoe: We can't tell intent at build time; we don't know if we have= a > shared link or a self-congested link.=A0 No matter what the intent is, it > might get misused in another situation.=A0 To reinforce Stuart: when we s= tart > an arms race, TCP squares the amount of congestion.=A0 If everyone puts i= n 2 > more, we get 4 times.=A0 10 more, 100 times, and then "congestive collaps= e". > > Richard Woundy, Comcast: I have a more fundamental question about this > document.=A0 Is it under active authorship?=A0 Are the authors continuing= ?=A0 They > didn't update the document, and they aren't here to present it.=A0 There = is > clearly a lot of work to do. > > Stas: I don't have an update on the status.=A0 If it turns out that we ne= ed > more contributors or another editor, it is easier to do if it is a WG > document under IETF change control.=A0 The WG can't find an editor for a > non-WG document. > > Lars: since there is no WG work item yet in this area, if someone wrote a > document that the WG liked better, that would move forward.=A0 If it is a= WG > work item, we could talk about replacing the editor. > > Stas: We did talk to the editor and he wanted it to become a WG work item= . > He is in Stockholm, but has fallen ill. > Lars: that explains why he is not presenting, but not why there is no > update. I hate to step on somebody's toes, but I'm hesitant if there is a > lack of editing cycles and the document is not a WG work item.=A0 This is= a > situation where we frequently run into problems. > > Bernard:=A0 Who is interested in working on this document and contributin= g to > it? > 2 folks raise their hands (Vijay and Richard Woundy). > Stas:=A0 This shall not go unpunished. > > Who thinks this document should be accepted as a WG work item? > Zero hands. > Who thinks it should not be accepted? > Two hands. > > Vijay:=A0 Since IETF 74, there has been no update, and it needed more wor= k. > Lars:=A0 Let's get a sense of how to move forward.=A0 If the document wer= e to be > updated a few times, would people think it could be ready, or will the > document never be ready? > > Who thinks it would be ready if worked on some more? > 11 people raise their hands. > > Who thinks that no matter how much effort goes into it, something is > fundamentally wrong? > Zero hands raised. > > Clear message: get an active editor and put in cycles. > > 14:10 - 14:30 A Survey of Lower-than-Best Effort Transport Protocols, M. > Welzl (20 minutes) > http://tools.ietf.org/html/draft-welzl-ledbat-survey > > This document is a literature review, to help us avoid reinventing the > wheel.=A0 The document looks at delay-based congestion algorithms, as wel= l as > application layer mechanisms. > > delay based algorithms > =A0=A0=A0 TCP Vegas.=A0 not designed to be lower than best efforts (LBE).= =A0 But nice > example, LBE in presence of Reno, but better if it is the only one. > > =A0=A0=A0 Others based on Vegas, but designed for LBE: TCP Nice, TCP-LP > > non-delay based > =A0 Also designed to give way, though growing less than TCP. > =A0 4CP, uses virtual window to limit congestion window earlier > =A0 MulTFRC. > =A0=A0=A0=A0=A0 0.1 weight.=A0 10x less agressive.=A0 But requires queue = growth, reacts > only to losses. > > app layer approaches. > =A0 so far, rcv window tuning.=A0 Some quite sophisticated ones > =A0 see SIGMETRICS 04 paper. > =A0=A0 claim: could work as well as transport-layer scheme > > Bernard:=A0 This document is under consideration for adoption as a WG wor= k > item.=A0=A0 Who wants to see it adopted? > Lars:=A0 This would be published as Informational. > > 18 hands. > Who doesn't want to see it adopted? > No hands. > > Consensus to be verified on the list. > > =3D=3D=3D=3D > 5 minute Item - Home Gate > Iljitsch van Beijnum > > Bar BOF Monday on home gateways:=A0 HOMEGATE. There is no charter, all is= up > in the air. > How much buffering should be in Home Gateways? > Wants people to send their info and thoughts about buffering and queueing > strategies. > join homegate@ietf.org or send feedback to Iljitsch: > www.ietf.org/mailman/listinfo/homegate > > > Stas - don't do things in HOMEGATE that make LEDBAT's job harder.=A0 Very > small buffer would make congestion control more difficult. Prefer the=A0 = "Do > no harm" criteria for recommendations. > > Bob Briscoe: Weighted Fair Queuing isn't designed for Homegateways -- don= 't > isolate the apps from each other. > Mark Handley - very small buffers on GigE links with high stat mux > Richard Woundy - 10 packets may not be enough buffer, 150ms to 200ms wort= h > <100 but more than 10 packets... > Dave Oran - the box that controls L2 state (e.g. 802.11 power save > buffering) has no interaction with the device L3 queuing. > Think Cable Modem: "Comcast, it's our fault."=A0 Back to Richard's commen= t: > need longer queue sometimes. > > > Next Steps and Wrapup (30 minutes) > > 14:30 - 15:00 Chairs & Area Directors (30 minutes) > > Nothing to Discuss - all votes were Unanimous. > > > > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat > > --=20 Stanislav Shalunov BitTorrent Inc shalunov@bittorrent.com personal: http://shlang.com From shalunov@bittorrent.com Fri Aug 7 11:42:43 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6876B3A6C7C for ; Fri, 7 Aug 2009 11:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drErPkbl3FQv for ; Fri, 7 Aug 2009 11:42:41 -0700 (PDT) Received: from mail-bw0-f220.google.com (mail-bw0-f220.google.com [209.85.218.220]) by core3.amsl.com (Postfix) with ESMTP id A0A6F3A6D6F for ; Fri, 7 Aug 2009 11:42:40 -0700 (PDT) Received: by bwz20 with SMTP id 20so1642269bwz.9 for ; Fri, 07 Aug 2009 11:42:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.119.82 with SMTP id y18mr375327faq.26.1249670560528; Fri, 07 Aug 2009 11:42:40 -0700 (PDT) Date: Fri, 7 Aug 2009 11:42:40 -0700 Message-ID: <6c82d1360908071142i6a676a3di6555d69d65ca4229@mail.gmail.com> From: Stanislav Shalunov To: dario.rossi@enst.fr, claudio.testa@enst.fr, Paolo Veglia Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ledbat@ietf.org Subject: [ledbat] News from the Internet congestion control world X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 18:42:44 -0000 Dario, Claudio, Paolo, Thank you for this contribution. I'm sure others will want to play with the model when it's available as well, so this will be valuable. It might be interesting to also run the simulation with a slightly modified measurement code. Perhaps adding a small random component to the measured off_target quantity to simulate real-world noise. Maybe something like an exponentially distributed deviate with a mean of a few milliseconds -- might make sense to try different things and see if it makes any difference. This should not affect the LEDBAT-TCP scenario, but might affect LEDBAT-LEDBAT scenarios. Thanks, -- Stas On Fri, Aug 7, 2009 at 10:19 AM, dario rossi wrote: > Dear all, > > > this message to inform you that we've been implementing a Ledbat module f= or > ns2, that we would like to share with the community as open source code. > > as the code requires a little bit of cleanup, we expect to put it on a > webpage after the summer (we'll announce on the mailing list as soon as i= t > will be ready) > > at the same time, we also would like to share some preliminary results wh= ich > are well in line with discussions going on in the list, and that are > accessible at: http://arxiv.org/abs/0908.0812 > > shortly, we find that late comer situations do arise; however, we also fi= nd > that a simple mean to break unfair situations could be to use slow-start = (as > this will let the flows loose some packets, allowing the capacity to drai= n > the queue, which in turn allows late comers to gather a good measurement = of > the base delay; more details in the paper) > > we have more activities going on, we expect to report on that after the > summer period as well. > > Best regards, > D. > > > -- > > Oo=A0=A0 Dario Rossi > =A0 >=A0=A0=A0 Ass. Prof. > ~=A0=A0=A0=A0 Telecom ParisTech > http://www.enst.fr/~drossi > > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat > > --=20 Stanislav Shalunov BitTorrent Inc shalunov@bittorrent.com personal: http://shlang.com From shalunov@bittorrent.com Fri Aug 7 12:12:43 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D779D3A67E5 for ; Fri, 7 Aug 2009 12:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRvqwzXYGwlS for ; Fri, 7 Aug 2009 12:12:42 -0700 (PDT) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by core3.amsl.com (Postfix) with ESMTP id 3A1E83A6DC1 for ; Fri, 7 Aug 2009 12:12:42 -0700 (PDT) Received: by fxm26 with SMTP id 26so1557353fxm.42 for ; Fri, 07 Aug 2009 12:12:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.126.10 with SMTP id a10mr410491fas.17.1249672359735; Fri, 07 Aug 2009 12:12:39 -0700 (PDT) In-Reply-To: <38549C92-ADAF-49E6-90D6-FEF082AF016D@apple.com> References: <38549C92-ADAF-49E6-90D6-FEF082AF016D@apple.com> Date: Fri, 7 Aug 2009 12:12:39 -0700 Message-ID: <6c82d1360908071212g4aae13dcp82fd3ede2da7aff7@mail.gmail.com> From: Stanislav Shalunov To: Stuart Cheshire Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ledbat@ietf.org Subject: Re: [ledbat] Confusion about clock terminology X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 19:12:43 -0000 On Wed, Jul 29, 2009 at 5:18 AM, Stuart Cheshire wrote: > Stanislav, > > In previous LEDBAT meetings I've been confused by your use of the term > "skew". I mention it because others may be confused too. > > NTP uses the terms "offset" (the difference between the instantaneous > absolute values of the clocks), "skew" (the difference between the *rates* > the clocks run, the rate of change of the offset) and "drift" (the rate of > change of the skew value). Stuart, Thank you for pointing it out. The draft uses NTP terminology throughout and I'll clarify that. The new text of the relevant paragraph: One-way delay measurement needs to deal with timestamp errors. We'll use the same locally linear clock model and the same terminology as Network Time Protocol (NTP). This model is valid for any differentiable clocks. NTP uses the term "offset" to refer to difference from true time and "skew" to refer to difference of clock rate from the true rate. The clock will thus have a fixed offset from the true time and a skew. We'll consider what we need to do about the offset and the skew separately. > To me this is odd. In normal conversation I think most people understand > "clock skew" to mean the absolute difference in current time, e.g. "Your > clock is three minutes ahead of mine," and "clock drift" to mean that this > difference changes over time, e.g. "Our clocks are drifting. Yesterday our > clocks were in sync but today your clock is three minutes ahead of mine." I always understood skew by mentally plotting the one-way delays measured in both directions. Without a clock skew, the lines are parallel. With it, they are not, and thus "skewed." Obviously, I'd be equally happy with any consistent terminology and went with NTP because there's an RFC for that. NTP's use of "drift" always sounded odd to me. Thanks for catching the ambiguity, -- Stas > There seems to be evidence of this common understanding: > > The "make" command's "clock skew detected" error refers to an absolute > offset in current clock value, not a difference in rates. > > In Kerberos, the term skew is used to refer to an absolute offset: > >> Hosts are configured to reject responses from any KDC whose clock is not >> within the specified maximum clock skew, as specified in the krb5.conf file. >> The default value for the maximum clock skew is five minutes (300 seconds). > > > The Wikipedia page also describes skew as the difference in time, not > difference in rate. > > > >> On a network such as the internet, clock skew describes the difference in >> time shown by the clocks at the different nodes on the network. It is >> usually an unavoidable phenomenon (at least if one looks at milli-second >> resolutions), but clock skew of tens of minutes or more is also quite >> common. > > > I'm not saying the NTP terminology is wrong, but used without clarification > it definitely invites misunderstanding. > > Stuart Cheshire > * Wizard Without Portfolio, Apple Inc. > * Internet Architecture Board > * www.stuartcheshire.org > > -- Stanislav Shalunov BitTorrent Inc shalunov@bittorrent.com personal: http://shlang.com From shalunov@bittorrent.com Fri Aug 7 14:39:54 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90F913A6B17 for ; Fri, 7 Aug 2009 14:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgUjsRyvEb-6 for ; Fri, 7 Aug 2009 14:39:53 -0700 (PDT) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by core3.amsl.com (Postfix) with ESMTP id 36DDF3A6EBD for ; Fri, 7 Aug 2009 14:39:39 -0700 (PDT) Received: by fxm26 with SMTP id 26so43396fxm.42 for ; Fri, 07 Aug 2009 14:39:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.121.193 with SMTP id i1mr235894far.57.1249681178328; Fri, 07 Aug 2009 14:39:38 -0700 (PDT) In-Reply-To: <55cb6be30907271538m36cfd56aj6cdb56399404071@mail.gmail.com> References: <55cb6be30907271538m36cfd56aj6cdb56399404071@mail.gmail.com> Date: Fri, 7 Aug 2009 14:39:38 -0700 Message-ID: <6c82d1360908071439n6806c45cr28dca49111f52b88@mail.gmail.com> From: Stanislav Shalunov To: Johan Pouwelse Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: ledbat@ietf.org Subject: Re: [ledbat] Commitment to contribute by P2P-next project X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 21:39:54 -0000 Johan, Sharing information explicitly among multiple connections from the same client is a promising area. (If I understood correctly the direction of what you're doing.) It'd be great to know more about the technique in question, and its applicability to various forms of congestion control. Is it a specific congestion control mechanism or a way to modify other congestion control mechanisms to take advantage of the knowledge that the upload is 1:n? Thanks, -- Stas On Mon, Jul 27, 2009 at 3:38 PM, Johan Pouwelse wrote: > Dear ledbat group, > > Hereby the P2P-Next research group commits itself to contributing to Ledb= at > a 'next-generation congestion control algorithm'. > > We have developed new algorithms and initial running Open Source code whi= ch > we are expanding. Before the end of this year we are planning to conduct = an > open Internet trial with over 50.000 participants. > P2P-Next is a European Union sponsored project with a budget of 19 millio= n > Euro. We are commited to use part of these resources to deploy and > standardize a novel congestion control algorithm. > We have reviewed in detail the current proposals on the Stockholm agenda. > Our key contribution due before end of 2009 is an algorithm which is > designed to move beyond the 1-to-1 context of current state-of-the-art. W= e > improve efficiency by utilising the fact that large majority of backgroun= d > upload traffic takes place in a 1 uploader to N receivers context. Our > initial measurements indicate that local and remote congestion can be > identified with superior accuracy if this context is exploited. > > From the strategic side we plan to be completely open about sharing of ou= r > Open Source code, algorithms and (anonymised) datasets. > > By contacting you prior to this meeting we hope that you can take our wor= k > into account when relevant. > The technical detail of our work will be given within a month from now. > > Greetings, > Dr. Johan pouwelse, scientific director of P2P-next. > > On Jul 27, 2009 5:48 AM, "Bernard Aboba" wrot= e: > > LEDBAT WG Meeting > IETF 75 > Stockholm, Sweden > > Chairs:=A0 S. Shalunov > =A0=A0=A0=A0=A0=A0=A0=A0 M. Sridharan > =A0=A0=A0=A0=A0=A0=A0=A0 B. Aboba (acting) > > Wednesday, July 29, 2009 > 13:00 - 15:00 > Congresshall B > > Preliminaries (10 minutes) > > Note well > Blue Sheets > Minute Takers > Jabber Scribe > Agenda bashing > Document Status > > Documents Under Consideration for Adoption as a WG Work Item (80 minutes) > > 13:10 - 13:40=A0 Low Extra Delay Background=A0 Transport (LEDBAT), S. Sha= lunov > (30 minutes) > http://tools.ietf.org/id/draft-shalunov-ledbat-congestion > > 13:40 =96 14:10 LEDBAT Practices and Recommendations, R. Penno (30 minute= s) > http://tools.ietf.org/id/draft-penno-ledbat-app-practices-recommendations > > 14:10 =96 14:30 A Survey of Lower-than-Best Effort Transport Protocols, M= . > Welzl (20 minutes) > http://tools.ietf.org/html/draft-welzl-ledbat-survey > > Next Steps and Wrapup (30 minutes) > > 14:30 =96 15:00 Chairs & Area Directors (30 minutes) > > > > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat > > > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat > > --=20 Stanislav Shalunov BitTorrent Inc shalunov@bittorrent.com personal: http://shlang.com From bernard_aboba@hotmail.com Sat Aug 8 08:59:47 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA34B3A659B for ; Sat, 8 Aug 2009 08:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.218 X-Spam-Level: X-Spam-Status: No, score=-0.218 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_50=0.001, HTML_FONT_SIZE_HUGE=0.057, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M41orb7LV53w for ; Sat, 8 Aug 2009 08:59:46 -0700 (PDT) Received: from blu0-omc4-s25.blu0.hotmail.com (blu0-omc4-s25.blu0.hotmail.com [65.55.111.164]) by core3.amsl.com (Postfix) with ESMTP id BC5113A6836 for ; Sat, 8 Aug 2009 08:59:46 -0700 (PDT) Received: from BLU137-W36 ([65.55.111.135]) by blu0-omc4-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 08:59:50 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_849d415b-730a-41ec-a5a7-b1a6d2b72a7a_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: Date: Sat, 8 Aug 2009 08:59:49 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 08 Aug 2009 15:59:50.0621 (UTC) FILETIME=[42CDE0D0:01CA1841] Subject: [ledbat] Summary: Call for Adoption of "Low Extra Delay Background Transport" as a LEDBAT WG work item X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2009 15:59:48 -0000 --_849d415b-730a-41ec-a5a7-b1a6d2b72a7a_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As reflected in the minutes=2C during the LEDBAT WG meeting at IETF 75=2C = there was consensus (18:0) for adoption of "Low Extra Delay Background Tran= sport" (draft-shulanov-ledbat-congestion) as a WG work item=2C with Experim= ental status. A request for confirmation was subsequently sent to the mail= ing list on July 29=2C 2009.=20 The request for confirmation=2C concluding on August 7=2C 2009 resulted in = additional comments on the document (see http://www.ietf.org/mail-archive/w= eb/ledbat/current/msg00172.html)=2C but no additional votes for or against = adoption. =20 The consensus of the LEDBAT WG meeting at IETF 75 is therefore confirmed. = After addressing the comments from the adoption call=2C draft-ietf-ledbat-c= ongestion will be submitted to the Internet-Drafts archive=2C becoming a LE= DBAT WG work item.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D During the IETF 75 LEDBAT WG meeting=2C the attendees indicated an interest in adopting "Low Extra Delay Background Transport" (draft-shulanov-ledbat-congestion) as a LEDBAT WG work item (with Experimental status). =20 =20 We would now like to verify the outcome of this call for adoption on the LEDBAT WG mailing list. The document is available for inspection here: http://tools.ietf.org/html/draft-shulanov-ledbat-congestion =20 If you did not raise your hand at the IETF 75 LEDBAT WG meeting=2C and have an opinion as to the suitability of adopting this document as a WG work item=2C please send mail to the LEDBAT WG list indicating your opinion (Yes/No/Abstain).=20 =20 The confirmation call for adoption will last until August 7=2C 2009. If you have issues/edits/comments on the document=2C please send these comments along to the list in your response to this Call for Adoption.=20 =20 Bernard Acting WG Co-Chair --_849d415b-730a-41ec-a5a7-b1a6d2b72a7a_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As reflected in the minutes=2C during the LEDBAT WG meeting at IETF 75=2C&n= bsp=3B there was consensus (18:0) for adoption of "Low Extra Delay Backgrou= nd Transport" (draft-shulanov-ledbat-congestion) as a WG work item=2C with = Experimental status. =3B A request for confirmation was subsequently se= nt to the mailing list on July 29=2C 2009.

The request for confirma= tion=2C concluding on August 7=2C 2009 resulted in additional comments on t= he document (see http://www.ietf.org/mail-archive/web/ledbat/current/msg001= 72.html)=2C but no additional votes for or against adoption. =3B
The consensus of the LEDBAT WG meeting at IETF 75 is therefore confirmed.=  =3B After addressing the comments from the adoption call=2C draft-ietf= -ledbat-congestion will be submitted to the Internet-Drafts archive=2C beco= ming a LEDBAT WG work item.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Du= ring the IETF 75 LEDBAT WG meeting=2C the attendees indicated an interest in adopting "Low Extra Delay Background Transport" (draft-shulanov-ledbat-congestion) as a LEDBAT WG work item (with Experimental status).  =3B
 =3B
We would now like to verify the outcome of =3Bthis call for adoption on the LEDBAT WG mailing list. =3B The document is available for inspectio= n here:
http://tools.ietf.org/html/draft-shulanov-ledbat-congestion
 =3B
If you did not raise your hand at the IETF 75 LEDBAT WG meeting=2C and have an opinion as to the suitability of adopting this document as a WG work item=2C please send mail to the LEDBAT WG list indicating your opinion (Yes/No/Abstain).
 =3B
The confirmation call for adoption will =3Blast until August 7=2C 2009.=  =3B If you have issues/edits/comments on the document=2C please send these comments along to the list in your response to this Call for Adoption. <= font face=3D"Arial-ItalicMT" size=3D"7">
  =3B
Bernard
Acting WG Co-Chair













= --_849d415b-730a-41ec-a5a7-b1a6d2b72a7a_-- From bernard_aboba@hotmail.com Sat Aug 8 09:04:28 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 590B83A6E3A for ; Sat, 8 Aug 2009 09:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.206 X-Spam-Level: X-Spam-Status: No, score=-0.206 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_50=0.001, HTML_FONT_SIZE_HUGE=0.057, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6keCe1FUmgqs for ; Sat, 8 Aug 2009 09:04:27 -0700 (PDT) Received: from blu0-omc4-s32.blu0.hotmail.com (blu0-omc4-s32.blu0.hotmail.com [65.55.111.171]) by core3.amsl.com (Postfix) with ESMTP id 083033A68E6 for ; Sat, 8 Aug 2009 09:03:40 -0700 (PDT) Received: from BLU137-W2 ([65.55.111.137]) by blu0-omc4-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Aug 2009 09:03:44 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_37745a78-036d-48de-912e-4dc179d599dc_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: Date: Sat, 8 Aug 2009 09:03:44 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 08 Aug 2009 16:03:44.0851 (UTC) FILETIME=[CE6A8A30:01CA1841] Subject: [ledbat] Summary: Call for adoption of "A Survey of Lower-than-Best Effort Transport Protocols" as a LEDBAT WG Work Item X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2009 16:04:28 -0000 --_37745a78-036d-48de-912e-4dc179d599dc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As reflected in the minutes=2C during the LEDBAT WG meeting at IETF 75=2C=20 there was consensus (18:0) for adoption of "A Survey of Lower-than-Best Eff= ort Transport Protocols" (draft-welzl-ledbat-survey) as a WG work item=2C w= ith Informational status. A request for confirmation was subsequently sent to the mailing list on July 29=2C 2009.=20 The request for confirmation=2C concluding on August 7=2C 2009 resulted in no additional comments on the document and no additional votes for or against adoption. =20 The consensus of the LEDBAT WG meeting at IETF 75 is therefore confirmed. After addressing any outstanding comments=2C draft-ietf-ledbat-= survey will be submitted to the Internet-Drafts archive=2C becoming a LEDBAT WG work item.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D During the IETF 75 LEDBAT WG meeting=2C the attendees indicated an interest in adopting "A Survey of Lower-than-Best Effort Transport Protocols" (draft-welzl-ledbat-survey) as a LEDBAT WG work item.=20 =20 We would now like to verify the outcome of this call for adoption on the LE= DBAT WG mailing list. =20 =20 If you did not raise your hand at the IETF 75 LEDBAT WG meeting=2C and have an opinion as to the suitability of adopting this document as a WG work item=2C please send mail to the LEDBAT WG list indicating your opinion (Yes/No/Abstain).=20 =20 The confirmation call for adoption will last until August 7=2C 2009. If you have issues/edits/comments on the document=2C please send these comments along to the list in your response to this Call for Adoption.=20 =20 Bernard Acting WG Co-Chair --_37745a78-036d-48de-912e-4dc179d599dc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As reflected in the minutes=2C during the LEDBAT WG meeting at IETF 75=2C&n= bsp=3B there was consensus (18:0) for adoption of "A Survey of Lower-than-Best Eff= ort Transport Protocols" (draft-welzl-ledbat-survey) as a WG work item=2C w= ith Informational status. =3B A request for confirmation was subsequent= ly sent to the mailing list on July 29=2C 2009.

The request for confirmation=2C concluding on August 7=2C 2009 resulted in no additional comments on the document and no additional votes for or against adoption. =3B

The consensus of the LEDBAT WG meeting at IETF 75 is therefore confirmed. =3B After addressing any outstanding comments=2C draft-ietf-= ledbat-survey will be submitted to the Internet-Drafts archive=2C becoming a LEDBAT WG work item.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
During the IETF 75 LEDBAT WG meeting= =2C the attendees indicated an interest in adopting "A Survey of Lower-than-Best Effort Transport Protocols" (draft-welzl-ledbat-survey)
as a LEDBAT WG work item.
 =3B
We would now like to verify the outcome of =3Bthis call for adoption on= the LEDBAT WG mailing list. =3B
 =3B
If you did not raise your hand at the IETF 75 LEDBAT WG meeting=2C and have an opinion as to the suitability of adopting this document as a WG work item=2C please send mail to the LEDBAT WG list indicating your opinion (Yes/No/Abstain).
 =3B
The confirmation call for adoption will =3Blast until August 7=2C 2009.=  =3B If you have issues/edits/comments on the document=2C please send these comments along to the list in your response to this Call for Adoption. <= font face=3D"Arial-ItalicMT" size=3D"7">
  =3B
Bernard
Acting WG Co-Chair




=
= --_37745a78-036d-48de-912e-4dc179d599dc_-- From touch@ISI.EDU Sat Aug 8 23:15:34 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61DE63A6A0E for ; Sat, 8 Aug 2009 23:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATnai50PtLRx for ; Sat, 8 Aug 2009 23:15:33 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id A42693A691B for ; Sat, 8 Aug 2009 23:15:33 -0700 (PDT) Received: from [192.168.1.46] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n796ExSZ029504; Sat, 8 Aug 2009 23:15:01 -0700 (PDT) Message-ID: <4A7E4543.5040903@isi.edu> Date: Sat, 08 Aug 2009 20:40:51 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Stanislav Shalunov References: <55cb6be30907271538m36cfd56aj6cdb56399404071@mail.gmail.com> <6c82d1360908071439n6806c45cr28dca49111f52b88@mail.gmail.com> In-Reply-To: <6c82d1360908071439n6806c45cr28dca49111f52b88@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: ledbat@ietf.org Subject: Re: [ledbat] Commitment to contribute by P2P-next project X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 06:15:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stanislav Shalunov wrote: > Johan, > > Sharing information explicitly among multiple connections from the > same client is a promising area. (If I understood correctly the > direction of what you're doing.) Sharing can be within a single client or among clients with similar properties (e.g., within a LAN). Both techniques are described in RFC2140 ;-) > It'd be great to know more about the technique in question, and its > applicability to various forms of congestion control. Is it a > specific congestion control mechanism or a way to modify other > congestion control mechanisms to take advantage of the knowledge that > the upload is 1:n? 2140 noted that in some cases you can help congestion control converge more quickly (or avoid competition between flows from the same machine) by doing a "divide by N", which can be adjusted to "divide by N+1" when you add a connection or "divide by N-1" when a connection ends. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkp+RUMACgkQE5f5cImnZruGxACfZxN/ngn3r2kXTDu6LAOo+RgQ DakAn2/dd/lELa67AcBIsuT9IoG5QILo =ZBV/ -----END PGP SIGNATURE----- From shalunov@bittorrent.com Sun Aug 9 14:30:12 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A16D3A680B for ; Sun, 9 Aug 2009 14:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTxCha+VH65Y for ; Sun, 9 Aug 2009 14:30:11 -0700 (PDT) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by core3.amsl.com (Postfix) with ESMTP id 051D53A693E for ; Sun, 9 Aug 2009 14:30:10 -0700 (PDT) Received: by fxm26 with SMTP id 26so715770fxm.42 for ; Sun, 09 Aug 2009 14:30:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.117.14 with SMTP id o14mr689877faq.96.1249853411832; Sun, 09 Aug 2009 14:30:11 -0700 (PDT) In-Reply-To: <4A7E4543.5040903@isi.edu> References: <55cb6be30907271538m36cfd56aj6cdb56399404071@mail.gmail.com> <6c82d1360908071439n6806c45cr28dca49111f52b88@mail.gmail.com> <4A7E4543.5040903@isi.edu> Date: Sun, 9 Aug 2009 14:30:11 -0700 Message-ID: <6c82d1360908091430l348c6734ncf9d260d92caf72b@mail.gmail.com> From: Stanislav Shalunov To: Joe Touch Content-Type: multipart/alternative; boundary=001636c5bab3a2339a0470bc2c1f Cc: ledbat@ietf.org Subject: Re: [ledbat] Commitment to contribute by P2P-next project X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 21:30:12 -0000 --001636c5bab3a2339a0470bc2c1f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sat, Aug 8, 2009 at 8:40 PM, Joe Touch wrote: > > Sharing can be within a single client or among clients with similar > properties (e.g., within a LAN). Both techniques are described in > RFC2140 ;-) Joe, I had two questions: 1. Do you expect this could be applicable to situations when connections share one endpoint but never another? 2. Let's call an information-sharing scheme split-resistant if the mean of the produced behavior of every flow remains the same when the scheme is active. Are all modifications in RFC 2140 intended to be split-resistant? (I see that a lot are, but maybe I'm missing something.) -- Stanislav Shalunov BitTorrent Inc shalunov@bittorrent.com personal: http://shlang.com --001636c5bab3a2339a0470bc2c1f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Aug 8, 2009 at 8:40 PM, Joe Touch <touch@isi.edu> wrote:
Sharing can be within a single client or among clients with similar
properties (e.g., within a LAN). Both techniques are described in
RFC2140 ;-)

Joe,

I= had two questions:

1. Do you expect this cou= ld be applicable to situations when connections share one endpoint but neve= r another?

2. Let's call an information-sharing scheme s= plit-resistant if the mean of the produced behavior of every flow remains t= he same when the scheme is active.=A0=A0Are all modifications in RFC 2140 i= ntended to be split-resistant? =A0(I see that a lot are, but maybe I'm = missing something.)

--
Stanislav Shalunov
BitTorrent Inc
shalunov@bittorrent.com

pers= onal: http://shlang.com
--001636c5bab3a2339a0470bc2c1f-- From touch@ISI.EDU Sun Aug 9 17:53:05 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 343CD3A6A57 for ; Sun, 9 Aug 2009 17:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fkeuKBeRvYH for ; Sun, 9 Aug 2009 17:53:04 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 7E8543A6B00 for ; Sun, 9 Aug 2009 17:53:04 -0700 (PDT) Received: from [192.168.1.46] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n7A0qqUH016308; Sun, 9 Aug 2009 17:52:54 -0700 (PDT) Message-ID: <4A7F6F64.2020706@isi.edu> Date: Sun, 09 Aug 2009 17:52:52 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Stanislav Shalunov References: <55cb6be30907271538m36cfd56aj6cdb56399404071@mail.gmail.com> <6c82d1360908071439n6806c45cr28dca49111f52b88@mail.gmail.com> <4A7E4543.5040903@isi.edu> <6c82d1360908091430l348c6734ncf9d260d92caf72b@mail.gmail.com> In-Reply-To: <6c82d1360908091430l348c6734ncf9d260d92caf72b@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: ledbat@ietf.org Subject: Re: [ledbat] Commitment to contribute by P2P-next project X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 00:53:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stanislav Shalunov wrote: > On Sat, Aug 8, 2009 at 8:40 PM, Joe Touch > wrote: > > Sharing can be within a single client or among clients with similar > properties (e.g., within a LAN). Both techniques are described in > RFC2140 ;-) > > Joe, > > I had two questions: > > 1. Do you expect this could be applicable to situations when connections > share one endpoint but never another? Sure. If the other end shares a prefix, it's likely they share a congestion point, so they probably can be shared. That's the key. If you suspect there's shared path properties, then coordinated connection management is appropriate. > 2. Let's call an information-sharing scheme split-resistant if the mean > of the produced behavior of every flow remains the same when the scheme > is active. Are all modifications in RFC 2140 intended to be > split-resistant? (I see that a lot are, but maybe I'm missing something.) 2140 explains that sharing is possible and consistent with existing congestion control (i.e., it makes things converge faster). It focuses on coarse properties - CWND, MSS, RTT, and lets each connection operate independently otherwise; with those mods, the changes in behavior focus on making the connections converge - not making N connections behave exactly like 1. 2140 doesn't specify the sharing alg in detail. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkp/b2QACgkQE5f5cImnZruuEQCgj01M5FJjbczO9+gIBw1YcFgA l2wAoOfkp6bfyKRIqFfDMrBlAQrDXaYH =XNVB -----END PGP SIGNATURE----- From lachlan.andrew@gmail.com Sun Aug 9 18:06:54 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCA073A6D87 for ; Sun, 9 Aug 2009 18:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Na2x3xg0duGD for ; Sun, 9 Aug 2009 18:06:53 -0700 (PDT) Received: from mail-gx0-f213.google.com (mail-gx0-f213.google.com [209.85.217.213]) by core3.amsl.com (Postfix) with ESMTP id C7CAC3A6D86 for ; Sun, 9 Aug 2009 18:06:53 -0700 (PDT) Received: by gxk9 with SMTP id 9so3751363gxk.13 for ; Sun, 09 Aug 2009 18:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hYn+IfPyhVSrpmGlnPHLIm+hcNeo8bWAexpukGnDsgU=; b=W+Aj63qi6yvnSxZWF2q8Nw+naNWXQ77hSF8DrizV+N0OVBkW+aq20dq8jfZOiRjnx0 Ae++7Ji0KXgYJhd1zqyu5Z9IwPCaMPHrmAJsntWzT1vTnEMRywWVgV21Kzz/IdOTiWgj uzKK2+rQxIcIFyRomCSMh6S43ycgtA7ySxCPI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=T5w9c53a5JzH3DcOnraprJJdWe9doVhajinNUoZknmTcHpc8kai3ETjq1JzVb8JbNh xiTPrptWI7O5kEuPqeEm3y04sVGonLR2clhdnBB0Loqq97v/8RZyV8Uav3Qbl/pOuQ2u fgzQYYdt+dnAfpT0LszAswnQIgwKJUiABGIcA= MIME-Version: 1.0 Received: by 10.150.211.9 with SMTP id j9mr4809371ybg.106.1249866415281; Sun, 09 Aug 2009 18:06:55 -0700 (PDT) In-Reply-To: <4A7F6F64.2020706@isi.edu> References: <55cb6be30907271538m36cfd56aj6cdb56399404071@mail.gmail.com> <6c82d1360908071439n6806c45cr28dca49111f52b88@mail.gmail.com> <4A7E4543.5040903@isi.edu> <6c82d1360908091430l348c6734ncf9d260d92caf72b@mail.gmail.com> <4A7F6F64.2020706@isi.edu> Date: Mon, 10 Aug 2009 11:06:55 +1000 Message-ID: From: Lachlan Andrew To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ledbat@ietf.org Subject: Re: [ledbat] Commitment to contribute by P2P-next project X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 01:06:55 -0000 2009/8/10 Joe Touch : > Stanislav Shalunov wrote: >> >> 1. Do you expect this could be applicable to situations when connections >> share one endpoint but never another? > > Sure. If the other end shares a prefix, it's likely they share a > congestion point, How much of a prefix should they share? If they share the first byte, that tells us almost nothing. Even if they share the same AS, the congestion point is likely to be towards the edge of the AS, which is highly likely not to be shared, isn't it? Cheers, Lachlan -- Lachlan Andrew Centre for Advanced Internet Architectures (CAIA) Swinburne University of Technology, Melbourne, Australia Ph +61 3 9214 4837 From lars.eggert@nokia.com Mon Aug 10 01:00:38 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 707513A6827 for ; Mon, 10 Aug 2009 01:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EI3zuQqEFjZk for ; Mon, 10 Aug 2009 01:00:37 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 6B68F3A6DAA for ; Mon, 10 Aug 2009 01:00:37 -0700 (PDT) Received: from [192.168.0.199] (funet-wlan.fit.nokia.com [195.148.124.254]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n7A80UDk008300 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 10 Aug 2009 11:00:30 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: Lachlan Andrew In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-13-1001085435; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 10 Aug 2009 11:00:24 +0300 References: <55cb6be30907271538m36cfd56aj6cdb56399404071@mail.gmail.com> <6c82d1360908071439n6806c45cr28dca49111f52b88@mail.gmail.com> <4A7E4543.5040903@isi.edu> <6c82d1360908091430l348c6734ncf9d260d92caf72b@mail.gmail.com> <4A7F6F64.2020706@isi.edu> X-Mailer: Apple Mail (2.936) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Mon, 10 Aug 2009 11:00:30 +0300 (EEST) Cc: "ledbat@ietf.org" Subject: Re: [ledbat] Commitment to contribute by P2P-next project X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 08:00:38 -0000 --Apple-Mail-13-1001085435 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 2009-8-10, at 4:06, Lachlan Andrew wrote: > How much of a prefix should they share? If they share the first byte, > that tells us almost nothing. Even if they share the same AS, the > congestion point is likely to be towards the edge of the AS, which is > highly likely not to be shared, isn't it? Section 2 of the Ensemble-TCP paper (link in a recent email) discusses this a bit. Lars --Apple-Mail-13-1001085435 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA4MTAwODAwMjVaMCMGCSqGSIb3DQEJBDEWBBSGvIB7J9U7aUtK qrrg0yjSZO71MjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAcWOVT7XwUqE8Fyx0CsS7E8C9XNHNCzZldGAjDMwwijT2uqaprSJI hAlLbnuMDR6raaawbIXmaqSStB3eyYoMZidjo8kHbffITJjkx4k1lyYh2Kw0HmbJ4drWKgp4n42Q q4TyejQC1UqyzQAjB+cTCtmEDKdh1wXm7EK5gnJm1aswGN2RbmYK0PbImN2MY4OsxaByGuhZdtKP FeUkP1xW9IELEi/UJotutM5MOyA/zvt/kexmXmmn9WaGXp5MecgXdgRCSPMbGw8ofXdX+lZ2qevg sY5xo4QQFEdYy/ObaKSu8qRUuT5cVitYxChF1YUHV3K+tH2qmnFD3Wa5vWkvjQAAAAAAAA== --Apple-Mail-13-1001085435-- From muraris@microsoft.com Mon Aug 10 11:02:54 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 372523A6EAE for ; Mon, 10 Aug 2009 11:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJdwkdn0s07s for ; Mon, 10 Aug 2009 11:02:53 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 2E31D28C114 for ; Mon, 10 Aug 2009 11:02:53 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Mon, 10 Aug 2009 11:02:56 -0700 Received: from TK5EX14MBXC121.redmond.corp.microsoft.com ([169.254.1.57]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi; Mon, 10 Aug 2009 11:02:56 -0700 From: Murari Sridharan To: Lachlan Andrew , Joe Touch Thread-Topic: [ledbat] Commitment to contribute by P2P-next project Thread-Index: AQHKDwsPR8Efh6Ynjkame4YGUfYOWJCbpmMAgAH3QYCAASrEgIAAOKEAgAAD7YCAAKXoIA== Date: Mon, 10 Aug 2009 18:01:57 +0000 Message-ID: <03520536067DF14395EA93FE7ECFDCF010A4CA@TK5EX14MBXC121.redmond.corp.microsoft.com> References: <55cb6be30907271538m36cfd56aj6cdb56399404071@mail.gmail.com> <6c82d1360908071439n6806c45cr28dca49111f52b88@mail.gmail.com> <4A7E4543.5040903@isi.edu> <6c82d1360908091430l348c6734ncf9d260d92caf72b@mail.gmail.com> <4A7F6F64.2020706@isi.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ledbat@ietf.org" Subject: Re: [ledbat] Commitment to contribute by P2P-next project X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 18:02:54 -0000 I guess the key would be to detect if you are sharing a path instead of pur= ely going by prefix. -----Original Message----- From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of= Lachlan Andrew Sent: Sunday, August 09, 2009 6:07 PM To: Joe Touch Cc: ledbat@ietf.org Subject: Re: [ledbat] Commitment to contribute by P2P-next project 2009/8/10 Joe Touch : > Stanislav Shalunov wrote: >> >> 1. Do you expect this could be applicable to situations when connections >> share one endpoint but never another? > > Sure. If the other end shares a prefix, it's likely they share a > congestion point, How much of a prefix should they share? If they share the first byte, that tells us almost nothing. Even if they share the same AS, the congestion point is likely to be towards the edge of the AS, which is highly likely not to be shared, isn't it? Cheers, Lachlan -- Lachlan Andrew Centre for Advanced Internet Architectures (CAIA) Swinburne University of Technology, Melbourne, Australia Ph +61 3 9214 4837 _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From touch@ISI.EDU Mon Aug 10 11:06:13 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE68E3A6C48 for ; Mon, 10 Aug 2009 11:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qh4o3oAWENr for ; Mon, 10 Aug 2009 11:06:12 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 746643A67EF for ; Mon, 10 Aug 2009 11:06:12 -0700 (PDT) Received: from [75.212.197.1] (1.sub-75-212-197.myvzw.com [75.212.197.1]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n7AI5koT021232; Mon, 10 Aug 2009 11:05:55 -0700 (PDT) Message-ID: <4A806179.20706@isi.edu> Date: Mon, 10 Aug 2009 11:05:45 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Murari Sridharan References: <55cb6be30907271538m36cfd56aj6cdb56399404071@mail.gmail.com> <6c82d1360908071439n6806c45cr28dca49111f52b88@mail.gmail.com> <4A7E4543.5040903@isi.edu> <6c82d1360908091430l348c6734ncf9d260d92caf72b@mail.gmail.com> <4A7F6F64.2020706@isi.edu> <03520536067DF14395EA93FE7ECFDCF010A4CA@TK5EX14MBXC121.redmond.corp.microsoft.com> In-Reply-To: <03520536067DF14395EA93FE7ECFDCF010A4CA@TK5EX14MBXC121.redmond.corp.microsoft.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "ledbat@ietf.org" Subject: Re: [ledbat] Commitment to contribute by P2P-next project X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 18:06:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Murari Sridharan wrote: > I guess the key would be to detect if you are sharing a path instead of purely going by prefix. Ultimately, yes. If you know there are shared path characteristics, then you know you can coordinate the state. Prefixes are just something to use as a correlator. Joe > > -----Original Message----- > From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of Lachlan Andrew > Sent: Sunday, August 09, 2009 6:07 PM > To: Joe Touch > Cc: ledbat@ietf.org > Subject: Re: [ledbat] Commitment to contribute by P2P-next project > > 2009/8/10 Joe Touch : >> Stanislav Shalunov wrote: >>> 1. Do you expect this could be applicable to situations when connections >>> share one endpoint but never another? >> Sure. If the other end shares a prefix, it's likely they share a >> congestion point, > > How much of a prefix should they share? If they share the first byte, > that tells us almost nothing. Even if they share the same AS, the > congestion point is likely to be towards the edge of the AS, which is > highly likely not to be shared, isn't it? > > Cheers, > Lachlan > > -- > Lachlan Andrew Centre for Advanced Internet Architectures (CAIA) > Swinburne University of Technology, Melbourne, Australia > > Ph +61 3 9214 4837 > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqAYXgACgkQE5f5cImnZrvOVACdEjKR4Ivd465luJnnehb4MvmU vO4AoMxmpb8LdNaWCTdpkABmlp5g3vai =lDi7 -----END PGP SIGNATURE----- From sw3588@att.com Wed Jul 29 05:11:36 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0423B3A6E92 for ; Wed, 29 Jul 2009 05:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.701 X-Spam-Level: X-Spam-Status: No, score=-104.701 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuseBSfwx+Oq for ; Wed, 29 Jul 2009 05:11:34 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id D50E33A7064 for ; Wed, 29 Jul 2009 05:11:33 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: sw3588@att.com X-Msg-Ref: server-3.tower-146.messagelabs.com!1248869491!5043168!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 6644 invoked from network); 29 Jul 2009 12:11:32 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-3.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Jul 2009 12:11:32 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n6TCBXjZ004172 for ; Wed, 29 Jul 2009 08:11:33 -0400 Received: from 01GAF5142010621.AD.BLS.COM (01GAF5142010621.ad.bls.com [139.76.131.79]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id n6TCBQ9R004088 for ; Wed, 29 Jul 2009 08:11:26 -0400 Received: from 01AL10015010626.AD.BLS.COM ([90.152.44.195]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 08:11:25 -0400 Received: from 01AL10015010652.AD.BLS.COM ([90.152.44.158]) by 01AL10015010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 07:11:25 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA1045.B26D4E33" Date: Wed, 29 Jul 2009 07:11:20 -0500 Message-ID: <938A352F605D9C469D35D3CAE82C49630E77526C@brexc52p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE:draft-shalunov-ledbat-congestion-00.txt thread-index: AcoQRa7LdiwqwTKvQK6HiK5o0yzlxQ== From: "Wright, Steven" To: X-OriginalArrivalTime: 29 Jul 2009 12:11:25.0693 (UTC) FILETIME=[B1E652D0:01CA1045] X-Mailman-Approved-At: Mon, 10 Aug 2009 11:13:12 -0700 Subject: Re: [ledbat] draft-shalunov-ledbat-congestion-00.txt X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 12:11:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1045.B26D4E33 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The presentation suggested that human perception provides guidance for some thresholds e.g. delay. Is this transport really intended for human interactive applications ? I though the targeted application space was more file transfer / machine-machine data synchronization etc. rather than twitch gaming applications ?? Would a better approach for parameters be to identify where too much delay starts to break things ?=20 regards,=20 Steven Wright, MBA,PhD.=20 Strategic Standards=20 AT&T Network Architecture=20 phone (404) 499 7030=20 fax (404) 986 6141=20 email steven.wright.3@att.com=20 ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA621 ------_=_NextPart_001_01CA1045.B26D4E33 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE:draft-shalunov-ledbat-congestion-00.txt

The = presentation = suggested that human perception provides guidance for some thresholds = e.g. delay.

Is this transport really intended for human interactive = applications ?  I though the targeted application space was more file = transfer / machine-machine data synchronization etc. rather than twitch gaming = applications ??

Would a better = approach  = for parameters be to identify where too much delay starts to break = things ?

regards,
Steven Wright, MBA,PhD.
Strategic = Standards
AT&T Network = Architecture
phone (404) 499 = 7030
fax (404) 986 6141
email = steven.wright.3@att.com =

*****

The information = transmitted is intended only for the person or entity to which it is = addressed and may contain confidential, proprietary, and/or privileged = material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or = entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the = material from all computers. GA621

 ------_=_NextPart_001_01CA1045.B26D4E33-- From sw3588@att.com Wed Jul 29 05:36:19 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50E8C3A684C for ; Wed, 29 Jul 2009 05:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.907 X-Spam-Level: X-Spam-Status: No, score=-104.907 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4anGC16L1F95 for ; Wed, 29 Jul 2009 05:36:18 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 616783A700B for ; Wed, 29 Jul 2009 05:36:18 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: sw3588@att.com X-Msg-Ref: server-2.tower-120.messagelabs.com!1248870977!24934901!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 10177 invoked from network); 29 Jul 2009 12:36:18 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-2.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Jul 2009 12:36:18 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n6TCaHEd012697 for ; Wed, 29 Jul 2009 08:36:17 -0400 Received: from 01GAF5142010625.AD.BLS.COM (01GAF5142010625.ad.bls.com [139.76.131.31]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id n6TCa9Zw012633 for ; Wed, 29 Jul 2009 08:36:11 -0400 Received: from 01AL10015010625.AD.BLS.COM ([90.152.44.194]) by 01GAF5142010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 08:36:09 -0400 Received: from 01AL10015010652.AD.BLS.COM ([90.152.44.158]) by 01AL10015010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 07:36:09 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA1049.26DA270F" Date: Wed, 29 Jul 2009 07:36:08 -0500 Message-ID: <938A352F605D9C469D35D3CAE82C49630E775292@brexc52p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: fairness... thread-index: AcoQSSXSJm+8Ln9yTHiBCIRW6v0Z0w== From: "Wright, Steven" To: X-OriginalArrivalTime: 29 Jul 2009 12:36:09.0440 (UTC) FILETIME=[26482600:01CA1049] X-Mailman-Approved-At: Mon, 10 Aug 2009 11:13:12 -0700 Subject: [ledbat] fairness... X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 12:36:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1049.26DA270F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is the fairness of LEDBAT vs TCP only during steady state ? Or is LEDBAT required to give preference to TCP transactions that do not reach steady state as well? I.e. you need to look at more than just the impact on steady state TCP throughput regards,=20 Steven Wright, MBA,PhD.=20 Strategic Standards=20 AT&T Network Architecture=20 phone (404) 499 7030=20 fax (404) 986 6141=20 email steven.wright.3@att.com=20 ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA625 ------_=_NextPart_001_01CA1049.26DA270F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable fairness...

Is the = fairness of LEDBAT vs TCP only during steady state ?

Or is LEDBAT = required to give preference to TCP transactions that do not reach steady = state  as = well?

I.e. you need to look at more than just the impact on = steady state TCP throughput

regards,
Steven Wright, MBA,PhD.
Strategic = Standards
AT&T Network = Architecture
phone (404) 499 = 7030
fax (404) 986 6141
email = steven.wright.3@att.com =

*****

The information = transmitted is intended only for the person or entity to which it is = addressed and may contain confidential, proprietary, and/or privileged = material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or = entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the = material from all computers. GA625

 ------_=_NextPart_001_01CA1049.26DA270F-- From shalunov@bittorrent.com Mon Aug 10 11:34:41 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 994AF3A6F32 for ; Mon, 10 Aug 2009 11:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ahsAZxHd2Jw for ; Mon, 10 Aug 2009 11:34:40 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id D51473A6F23 for ; Mon, 10 Aug 2009 11:34:14 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 28so1143665wff.31 for ; Mon, 10 Aug 2009 11:34:17 -0700 (PDT) Received: by 10.142.214.5 with SMTP id m5mr233814wfg.341.1249929257076; Mon, 10 Aug 2009 11:34:17 -0700 (PDT) Received: from ?192.168.1.105? (c-67-188-254-19.hsd1.ca.comcast.net [67.188.254.19]) by mx.google.com with ESMTPS id 9sm12961495wfc.36.2009.08.10.11.34.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Aug 2009 11:34:15 -0700 (PDT) References: <938A352F605D9C469D35D3CAE82C49630E77526C@brexc52p> Message-Id: From: Stanislav Shalunov To: "Wright, Steven" In-Reply-To: <938A352F605D9C469D35D3CAE82C49630E77526C@brexc52p> Content-Type: multipart/alternative; boundary=Apple-Mail-7-1039109026 Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7A400) Mime-Version: 1.0 (iPhone Mail 7A400) Date: Mon, 10 Aug 2009 11:34:02 -0700 Cc: "" Subject: Re: [ledbat] draft-shalunov-ledbat-congestion-00.txt X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 18:34:41 -0000 --Apple-Mail-7-1039109026 Content-Type: text/plain; charset=windows-1251; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Jul 29, 2009, at 5:11 AM, "Wright, Steven" wrote: > The presentation suggested that human perception provides guidance =20 > for some thresholds e.g. delay. > Yes, as one of several other considerations such as =95 large enough to be robustly differentiable from 0 =95 small enough as a fraction of speed-of-light WAN RTT > Is this transport really intended for human interactive =20 > applications ? I though the targeted application space was more =20 > file transfer / machine-machine data synchronization etc. rather =20 > than twitch gaming applications ?? > Games and VoIP might share a bottleneck, thus experiencing the shared =20= delay. > Would a better approach for parameters be to identify where too =20 > much delay starts to break things ? > Right. We have to consider *other* things that can be broken, too, not =20= just the stuff inside the protocol, though.= --Apple-Mail-7-1039109026 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Jul = 29, 2009, at 5:11 AM, "Wright, Steven" <sw3588@att.com> = wrote:

The = presentation = suggested that human perception provides guidance for some thresholds = e.g. delay.

Yes, as one of = several other considerations such as

=E2=80=A2 = large enough to be robustly differentiable from = 0

=E2=80=A2 small enough as a fraction of = speed-of-light WAN RTT

Is this transport really intended for human interactive = applications ?  I though the targeted application space was more file = transfer / machine-machine data synchronization etc. rather than twitch gaming = applications ??

Games and VoIP = might share a bottleneck, thus experiencing the shared = delay. 

Would a = better approach  for parameters = be to identify where too much = delay starts to break things ?

Right. We = have to consider *other* things that can be broken, too, not just the = stuff inside the protocol, though.= --Apple-Mail-7-1039109026-- From shalunov@bittorrent.com Mon Aug 10 11:39:46 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 986F33A6EF4 for ; Mon, 10 Aug 2009 11:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[AWL=-0.622, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eA0Fp8iYAxdu for ; Mon, 10 Aug 2009 11:39:45 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id B91CE3A6892 for ; Mon, 10 Aug 2009 11:39:45 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 28so1144812wff.31 for ; Mon, 10 Aug 2009 11:39:47 -0700 (PDT) Received: by 10.142.157.1 with SMTP id f1mr863817wfe.85.1249929587839; Mon, 10 Aug 2009 11:39:47 -0700 (PDT) Received: from ?192.168.1.105? (c-67-188-254-19.hsd1.ca.comcast.net [67.188.254.19]) by mx.google.com with ESMTPS id 31sm12920488wff.38.2009.08.10.11.39.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Aug 2009 11:39:46 -0700 (PDT) References: <938A352F605D9C469D35D3CAE82C49630E775292@brexc52p> Message-Id: From: Stanislav Shalunov To: "Wright, Steven" In-Reply-To: <938A352F605D9C469D35D3CAE82C49630E775292@brexc52p> Content-Type: multipart/alternative; boundary=Apple-Mail-8-1039438589 Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7A400) Mime-Version: 1.0 (iPhone Mail 7A400) Date: Mon, 10 Aug 2009 11:39:32 -0700 Cc: "" Subject: Re: [ledbat] fairness... X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 18:39:46 -0000 --Apple-Mail-8-1039438589 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit The Ledbat backoff starts as delay starts to climb and so before loss occurs. TCP backoff only happens when loss does. This does not require the TCP connections to be in steady state, or ever reach it. This is an important consideration and thanks for bringing it up. HTTP connections are often so short-lived they don't make it to a steady state. Stanislav Shalunov On Jul 29, 2009, at 5:36 AM, "Wright, Steven" wrote: > Is the fairness of LEDBAT vs TCP only during steady state ? > > Or is LEDBAT required to give preference to TCP transactions that do > not reach steady state as well? > > I.e. you need to look at more than just the impact on steady state > TCP throughput > > regards, > Steven Wright, MBA,PhD. > Strategic Standards > AT&T Network Architecture > phone (404) 499 7030 > fax (404) 986 6141 > email steven.wright.3@att.com > > > ***** > > The information transmitted is intended only for the person or > entity to which it is addressed and may contain confidential, > proprietary, and/or privileged material. Any review, retransmission, > dissemination or other use of, or taking of any action in reliance > upon this information by persons or entities other than the intended > recipient is prohibited. If you received this in error, please > contact the sender and delete the material from all computers. GA625 > > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat --Apple-Mail-8-1039438589 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
The Ledbat backoff starts as delay starts to climb and so before loss occurs. TCP backoff only happens when loss does.  This does not require the TCP connections to be in steady state, or ever reach it. 

This is an important consideration and thanks for bringing it up. HTTP connections are often so short-lived they don't make it to a steady state. 

Stanislav Shalunov

On Jul 29, 2009, at 5:36 AM, "Wright, Steven" <sw3588@att.com> wrote:

Is the fairness of LEDBAT vs TCP only during steady state ?

Or is LEDBAT required to give preference to TCP transactions that do not reach steady state  as well?

I.e. you need to look at more than just the impact on steady state TCP throughput

regards,
Steven Wright, MBA,PhD.
Strategic Standards
AT&T Network Architecture
phone (404) 499 7030
fax (404) 986 6141
email steven.wright.3@att.com

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625

_______________________________________________
ledbat mailing list
ledbat@ietf.org
https://www.ietf.org/mailman/listinfo/ledbat
--Apple-Mail-8-1039438589--