Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D2121F8B24 for ; Mon, 3 Oct 2011 03:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.043 X-Spam-Level: X-Spam-Status: No, score=-5.043 tagged_above=-999 required=5 tests=[AWL=0.671, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pckC7aSwl7oF for ; Mon, 3 Oct 2011 03:53:17 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5981D21F8AE9 for ; Mon, 3 Oct 2011 03:53:12 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-b7-4e8994cd42d8 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.115.84]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 1F.58.20773.DC4998E4; Mon, 3 Oct 2011 12:56:13 +0200 (CEST) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.2.123]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 3 Oct 2011 12:55:11 +0200 From: Ingemar Johansson S To: Henrik Lundin , Jim Gettys Date: Mon, 3 Oct 2011 12:55:09 +0200 Thread-Topic: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt) Thread-Index: AcyBpE2UIRiG7Lx4S3WXU1HWwteK4QAAYQrg Message-ID: References: <4E649FBD.1090001@alvestrand.no> <4E734E89.5010105@ericsson.com> <4E766C4C.2020201@jesup.org> <4E787D56.8060106@alvestrand.no> <4E788A9C.40105@alvestrand.no> <4E799F00.8030602@alvestrand.no> <4E79E698.2090905@jesup.org> <4E79EA16.7070909@freedesktop.org> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: multipart/alternative; boundary="_000_DBB1DC060375D147AC43F310AD987DCC36AE894DEBESESSCMS0366e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 10:53:21 -0000 --_000_DBB1DC060375D147AC43F310AD987DCC36AE894DEBESESSCMS0366e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I guess one thing that should be considered is that a mobile user may make = handover between different radio access types with large differences in ter= ms of e.g throughput. You may have scenarios such as handover from LTE to G= PRS or perhaps you have handover from WiFi to HSPA if a user walks away fro= m a caf=E9. I would expect that these scenarios will become very common in = the future. It is also worth mention that handover between WiFi and 3GPP i= s standardized in 3GPP, which in practice means that this will ultimately h= appen without end user interaction. What the endpoints will notice is poten= tially a large and sudden change in throughput. In cases like these thoughput may drop rapidly. Of course you can sense thi= s with the outlined algoritms that signals feedback only when needed but th= at assumes that you receive packets that you can infer enough statistics on= . Problem is that on the receiver side don't really know that you are about= to receive a packet. With ACK-clocked algorithms like TCP and TFWC the sender simply stops sendi= ng packets when ACK's are not received anymore. Receiver based algos are a = bit more complicated as the risk is higher that the sender will continue to= send packets for some time even though the channel throughput has dropped = considerably, resulting in excessive congestion somewhere along the path. Is this a problem ?. I don't know, I guess time will tell. /Ingemar ________________________________ From: Henrik Lundin [mailto:hlundin@google.com] Sent: den 3 oktober 2011 10:13 To: Jim Gettys Cc: Randell Jesup; rtcweb@ietf.org Subject: Re: [rtcweb] An input for discussing congestion control (Fwd: New = Version Notification for draft-alvestrand-rtcweb-congestion-00.txt) Sorry for my late response. (I've been away for some time.) I'd just like t= o add my two cents to the discussion on feedback latency. Frequent and rapid feedback is important to ensure stability of the CC; I t= hink we all agree. However, with an algorithm similar to the suggested one,= having a receive-side processing and analysis function, the key feature is= that feedback _can_ be sent quickly when needed. When everything is ok, fe= edback can be quite sparse, as long as the rate increments are somewhat adj= usted for the system response time (including the feedback latency). When c= ongestion is detected by the receiver, it is important that a feedback mess= age can be sent more or less immediately (say, within 100 ms). However, I d= o not see the need for constant feedback every RTT or so. /Henrik On Wed, Sep 21, 2011 at 3:43 PM, Jim Gettys > wrote: On 09/21/2011 09:28 AM, Randell Jesup wrote: On 9/21/2011 4:23 AM, Harald Alvestrand wrote: I think receiver->sender reporting every RTT (or every packet, which is fre= quently less frequent) is overkill, but that's a statement with a lot of gu= t feeling and very few numbers behind it. One advantage we have in RTCWEB is that we can assume that if audio and vid= eo work OK across the network, we're in a good place. We don't have to worr= y about getting gigabyte file transfers to utilize 90% of the link - even t= hogh we have to worry about audio and video functioning while those gigabyt= e transfers are taking place. Agreed. Also, in practice the TCP flows we're competing with are rarely lo= ng-lived high-bandwidth flows like GB file transfers. Normally they're flurries of = short-lived TCP (which is important to consider since these short-lived flows can suddenly = cause buffering without warning). You get to deal with some of each. Both cause havoc in the face of bufferbl= oat. The long lived flows keep the buffers in your OS/Home router/broadban= d gear near full, inserting lots of delay. This includes doing backups (lo= cal or remote), uploading videos, downloading videos to disk, bittorrent, e= tc. The netalyzr data is quite grim, particularly when you realise it's a l= ower bound on the problem (the netalyzr test is sensitive to cross traffic = and more importantly, tops out by the time it gets to 20Mbps). http://gettys.wordpress.com/2010/12/06/whose-house-is-of-glasse-must-not-th= row-stones-at-another/ As far as the transient bufferbloat problem caused by web traffic, and why = IW10 is a problem in my view at this time, see: http://www.ietf.org/id/draft-gettys-iw10-considered-harmful-00.txt As for 1 feedback/RTT, I agree. And if you wanted to use one feedback/RTT,= I'd put the feedback in a TCP header extension or design an RTP equivalent that can carry it in the= reverse-direction media flow (when available). But that's a different argument. I like timestamps, if only to make it easy to tell the user: you are losing= , and it's because of your broken network. For TCP, the TCP timestamp option is on by default in Linux, and I think ma= y be on by default on other modern systems (anyone have any data?). - Jim Other protocols may not be so nice. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb -- Henrik Lundin | WebRTC Software Eng | hlundin@google.com | +46 70 646 13 41 --_000_DBB1DC060375D147AC43F310AD987DCC36AE894DEBESESSCMS0366e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
 
I=20 guess one thing that should be considered is that a mobile user may make=20 handover between different radio access types with large differences in ter= ms of=20 e.g throughput. You may have scenarios such as handover from LTE to GPRS or= =20 perhaps you have handover from WiFi to HSPA if a user walks away from a caf= =E9. I=20 would expect that these scenarios will become very common in the future. It= is=20 also worth mention that handover between  WiFi and 3GPP is=20 standardized in 3GPP, which in practice means that this will ultimately hap= pen=20 without end user interaction. What the endpoints will notice is potent= ially=20 a large and sudden change in throughput.
 
In cases like these thoughput may dro= p rapidly.=20 Of course you can sense this with the outlined algoritms that signals feedb= ack=20 only when needed but that assumes that you receive packets that you can inf= er=20 enough statistics on. Problem is that on the receiver side don't really kno= w=20 that you are about to receive a packet.
With=20 ACK-clocked algorithms like TCP and TFWC the sender simply stops sending pa= ckets=20 when ACK's are not received anymore. Receiver based algos are a bit more=20 complicated as the risk is higher that the sender will continue to send pac= kets=20 for some time even though the channel throughput has dropped considera= bly,=20 resulting in excessive congestion somewhere along the path.
 
Is=20 this a problem ?. I don't know, I guess time will tell.
 
/Ingemar

From: Henrik Lundin=20 [mailto:hlundin@google.com]
Sent: den 3 oktober 2011=20 10:13
To: Jim Gettys
Cc: Randell Jesup;=20 rtcweb@ietf.org
Subject: Re: [rtcweb] An input for discussing=20 congestion control (Fwd: New Version Notification for=20 draft-alvestrand-rtcweb-congestion-00.txt)

Sorry for my late response. (I've been away for some time.) I'= d=20 just like to add my two cents to the discussion on feedback latency.

Frequent and rapid feedback is important to ensure stability of the = CC; I=20 think we all agree. However, with an algorithm similar to the suggested o= ne,=20 having a receive-side processing and analysis function, the key feature i= s=20 that feedback _can_ be sent quickly when needed. When everything is ok,=20 feedback can be quite sparse, as long as the rate increments are somewhat= =20 adjusted for the system response time (including the feedback latency). W= hen=20 congestion is detected by the receiver, it is important that a feedback=20 message can be sent more or less immediately (say, within 100 ms). Howeve= r, I=20 do not see the need for constant feedback every RTT or so.

/Henrik





On Wed, Sep 21, 2011 at 3:43 PM, Jim Gettys <jg@freedesktop.org> wrote:

On 09/21/2011 09:28 AM, Randell Jesup wrote:=20
On 9/21/2011 4:23 AM, Harald Alvestrand wrote= :=20
I think receiver->sender reporting every= RTT=20 (or every packet, which is frequently less frequent) is overkill, b= ut=20 that's a statement with a lot of gut feeling and very few numbers b= ehind=20 it.

One advantage we have in RTCWEB is that we can assume t= hat=20 if audio and video work OK across the network, we're in a good plac= e. We=20 don't have to worry about getting gigabyte file transfers to utiliz= e 90%=20 of the link - even thogh we have to worry about audio and video=20 functioning while those gigabyte transfers are taking place.=20

Agreed.  Also, in practice the TCP flows we= 're=20 competing with are rarely long-lived
high-bandwidth flows like GB= file=20 transfers.  Normally they're flurries of short-lived TCP
(wh= ich=20 is important to consider since these short-lived flows can suddenly c= ause=20 buffering
without warning).

You get to= deal=20 with some of each. Both cause havoc in the face of bufferbloat.  T= he=20 long lived flows keep the buffers in your OS/Home router/broadband gear= near=20 full, inserting lots of delay.  This includes doing backups (local= or=20 remote), uploading videos, downloading videos to disk, bittorrent, etc.= The=20 netalyzr data is quite grim, particularly when you realise it's a lower= =20 bound on the problem (the netalyzr test is sensitive to cross traffic a= nd=20 more importantly, tops out by the time it gets to 20Mbps).

http://gettys.wordpress.com/2010/12/06/whose-house-is-o= f-glasse-must-not-throw-stones-at-another/

As=20 far as the transient bufferbloat problem caused by web traffic, and why= IW10=20 is a problem in my view at this time, see:

http://www.ietf.org/id/draft-gettys-iw10-considered-har= mful-00.txt



As for 1 feedback/RTT, I agree.  And= if=20 you wanted to use one feedback/RTT, I'd put the feedback in
a TCP= =20 header extension or design an RTP equivalent that can carry it in the= =20 reverse-direction
media flow (when available).  But that's a= =20 different argument.

I like timestamps, if = only to=20 make it easy to tell the user: you are losing, and it's because of your= =20 broken network.

For TCP, the TCP timestamp option is on by defau= lt in=20 Linux, and I think may be on by default on other modern systems (anyone= have=20 any data?).
           = =20             -=20 Jim


Other protocols may not be so=20 nice.

_______________________________________________
r= tcweb=20 mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


--
Henrik=20 Lundin | WebRTC=20 Software Eng | hlundin@google.com | +46=20 70 646 13 41


--_000_DBB1DC060375D147AC43F310AD987DCC36AE894DEBESESSCMS0366e_--