From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "rcdn-iport.cisco.com", Issuer "HydrantID SSL ICA G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 04B9321F208 for ; Mon, 27 Apr 2015 07:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7824; q=dns/txt; s=iport; t=1430146253; x=1431355853; h=from:to:subject:date:message-id:mime-version; bh=FebqEBGHVFNDu30ZkDA28VXEruwxvI3vv8eb4+e5p4s=; b=ewYGbypFNm+GPMSEY/9ppFTVK2JZtDZSVLJzwXJ3gyftREPZj2zzT692 x0ec/N+XTE5sTdTKDwqwCISr5gwLbYL0sJhCYarhjS5MurhPFz3dyT9JY JgOIWwtaypo0HzAFwRgGdpZfVpGNIZMDsTNK0IEyowIAC8eqw8kcNW2U1 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CuBQCDSz5V/5hdJa1cgkVHU10ExhCCBYYEAoEyTAEBAQEBAYELhCIBBCcGXgEqViYBBBuIIw2jQKNGAQEBAQYBAQEBHo9yGoNPgRYFkVWEAZJXiUIjggccgVGCM4EAAQEB X-IronPort-AV: E=Sophos;i="5.11,657,1422921600"; d="scan'208,217";a="415169701" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 27 Apr 2015 14:49:31 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t3REnVHu004976 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 27 Apr 2015 14:49:31 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.175]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Mon, 27 Apr 2015 09:49:31 -0500 From: "Bill Ver Steeg (versteb)" To: "bloat@lists.bufferbloat.net" Thread-Topic: sch_fq and sk->sk_pacing_rate Thread-Index: AdCA+Y0yQ6uKea+qRLaAqAY7d4B5KQ== Date: Mon, 27 Apr 2015 14:49:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.210.114] Content-Type: multipart/alternative; boundary="_000_AE7F97DB5FEE054088D82E836BD15BE9319C342Bxmbalnx05ciscoc_" MIME-Version: 1.0 Subject: [Bloat] sch_fq and sk->sk_pacing_rate X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 14:50:54 -0000 --_000_AE7F97DB5FEE054088D82E836BD15BE9319C342Bxmbalnx05ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bloaters (and particularly Eric) I will try to not confuse the list, as this question is about host behavior= s rather than middlebox behaviors. Having said that...... I am playing around with some application code that would benefit from paci= ng. The example I have in mind is MPEG-DASH style vide, but any type of ABR= flow would probably benefit from the scheme I have in mind. I have done so= me work with client based pacing via RWND, but it is very clunky. I am thinking of having the server tell the kernel the rate at which it wan= ts data delivered to the client. (The client would probably tell the server= via an HTTP pragma, but that is a separate can of worms....) So, the HTTP = server would tell the kernel that it wants to deliver the TCP data at or be= low a certain max rate. There are currently hooks in sch_fq for the TCP lay= er to set sk_pacing_rate. It seems that I would need to add another pacing = variable and have the data sent at the min of q->flow_max_rate, skb->sk->sk= _pacing_rate, and this new app_pacing_rate. In other words, the old code rate =3D q->flow_max_rate; if (skb->sk) rate =3D min(skb->sk->sk_pacing_rate, rate); would become rate =3D q->flow_max_rate; if (skb->sk) { rate =3D min(skb->sk->sk_pacing_rate, rate); if (skb->sk->app_pacing_rate) rate =3D (min(skb->sk->app_pacing_rate, rate); } Thoughts? Bill VerSteeg --_000_AE7F97DB5FEE054088D82E836BD15BE9319C342Bxmbalnx05ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bloaters (and particularly Eric)

 

I will try to not confuse the list, as this question= is about host behaviors rather than middlebox behaviors. Having said that&= #8230;…

 

I am playing around with some application code that = would benefit from pacing. The example I have in mind is MPEG-DASH style vi= de, but any type of ABR flow would probably benefit from the scheme I have = in mind. I have done some work with client based pacing via RWND, but it is very clunky.

 

I am thinking of having the server tell the kernel t= he rate at which it wants data delivered to the client. (The client would p= robably tell the server via an HTTP pragma, but that is a separate can of w= orms….) So, the HTTP server would tell the kernel that it wants to deliver the TCP data at or below a certai= n max rate. There are currently hooks in sch_fq for the TCP layer to set sk= _pacing_rate. It seems that I would need to add another pacing variable and= have the data sent at the min of q->flow_max_rate, skb->sk->sk_pacing_rate, and this new app_pacin= g_rate. In other words, the old code

 

rate =3D q->flow_max_rate;
if (skb->sk)
   rate =3D min(skb->sk->sk_pacing_rate, rate);

 

would become

 

rate =3D q->flow_max_rate;
if (skb->sk)
{
    rate =3D min(skb->sk->sk_pacing_rate, rate);
    if (skb->sk->app_pacing_rat=
e)
        rate =3D =
(min(skb->sk->app_pacing_rate, rate);
}      

 

 

Thoughts?

 

Bill VerSteeg

--_000_AE7F97DB5FEE054088D82E836BD15BE9319C342Bxmbalnx05ciscoc_--