[jira] [Updated] (TS-2644) TOS (DSCP)

2014-04-29 Thread Jay Tomolek (JIRA)

 [ 
https://issues.apache.org/jira/browse/TS-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jay Tomolek updated TS-2644:


Attachment: domain_tos.cc

Here's the plugin code
Cheers, 
JT

 TOS (DSCP) 
 ---

 Key: TS-2644
 URL: https://issues.apache.org/jira/browse/TS-2644
 Project: Traffic Server
  Issue Type: New Feature
  Components: Cache, Network
Reporter: Faysal Banna
 Fix For: 5.0.0

 Attachments: domain_tos.cc


 Hi Guys 
 I wonder if it would be possible to have a plugin that we can assign TOS/DSCP 
 bits to the objects that are being a cache HIT or maybe object type of 
 video/audio. 
 such a plugin would give us better performance and control on how to 
 distribute the output of the cache towards clients. 
 example : 
 suppose i set traffic to clients each of different bandwidth. 
 on a router on a link somewhere on some roof top building i can say this 
 client can get miss object traffic of 512Kbit/s and 1Mbit/s of Hits from the 
 cache. 
 this way if this client is getting a cached object he would get it in 1Mbit/s 
 while his non cached requests would be of 512Kbit/s 
 hope whoever does this patch plugin takes into consideration the mime type or 
 url of the object being retrieved maybe i want to set audio/video being 
 cached or not to have 768Kbit/s while windows updates and android/iphone apps 
 should take no more than 512kbit/s 
 bear in mind that this has nothing to do with Origin servers throttling 
 feature request. this is just client side feature set. 
 much regards 
 Faysal Banna



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (TS-698) LogFilter should support an actual IP type and matching rules

2014-04-27 Thread Jay Tomolek (JIRA)

 [ 
https://issues.apache.org/jira/browse/TS-698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jay Tomolek updated TS-698:
---

Attachment: logfilterip.patch

patch file to enable LogFilterIP 

 LogFilter should support an actual IP type and matching rules
 -

 Key: TS-698
 URL: https://issues.apache.org/jira/browse/TS-698
 Project: Traffic Server
  Issue Type: Improvement
  Components: Logging
Affects Versions: 2.1.6
 Environment: N/A
Reporter: Eric Connell
Assignee: Alan M. Carroll
Priority: Minor
 Fix For: sometime

 Attachments: logfilterip.patch


 The LogFilter configuration in logs_xml.config should support a native IPv4 
 and IPv6 filtering.  For example, it would be handy to be able to filter out 
 log lines from a specific server or netblock.  For example, the following 
 config would reject log lines for all hosts in the 10/8 network:
 {code}
 LogFilter
 Name = local_net/
 Condition = chi MATCH 10.0.0.0/8/
 Action = REJECT/
 /LogFilter 
   
 LogFormat
   Name = access_log/
   Format = %shi/
 /LogFormat 
 LogObject 
   Format = access_log/
   Filename = access_log/
   Filters = local_net/
 /LogObject 
 {code} 



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Commented] (TS-698) LogFilter should support an actual IP type and matching rules

2014-04-26 Thread Jay Tomolek (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13982087#comment-13982087
 ] 

Jay Tomolek commented on TS-698:


hi,
i've developed a patch to handle this issue allowing MATCH operator over 
LogField::IP fields (chi, shi, phi).

it was implemented as LogFilterIP, quite similiar to LogFilterInt code, 
allowing single or multiple IP matchs (comma separated) , such as:

LogFilter
Name = reject_localhost_requests/
Condition = chi MATCH 127.0.0.1/
Action = REJECT/
/LogFilter

LogFilter
Name = apache_org_responses/
Condition = chi MATCH 192.87.106.229,140.211.11.131/
Action = ACCEPT/
/LogFilter


 LogFilter should support an actual IP type and matching rules
 -

 Key: TS-698
 URL: https://issues.apache.org/jira/browse/TS-698
 Project: Traffic Server
  Issue Type: Improvement
  Components: Logging
Affects Versions: 2.1.6
 Environment: N/A
Reporter: Eric Connell
Assignee: Alan M. Carroll
Priority: Minor
 Fix For: sometime


 The LogFilter configuration in logs_xml.config should support a native IPv4 
 and IPv6 filtering.  For example, it would be handy to be able to filter out 
 log lines from a specific server or netblock.  For example, the following 
 config would reject log lines for all hosts in the 10/8 network:
 {code}
 LogFilter
 Name = local_net/
 Condition = chi MATCH 10.0.0.0/8/
 Action = REJECT/
 /LogFilter 
   
 LogFormat
   Name = access_log/
   Format = %shi/
 /LogFormat 
 LogObject 
   Format = access_log/
   Filename = access_log/
   Filters = local_net/
 /LogObject 
 {code} 



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Commented] (TS-2644) TOS (DSCP)

2014-04-26 Thread Jay Tomolek (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13982100#comment-13982100
 ] 

Jay Tomolek commented on TS-2644:
-

hi guys,
i coded in the past a plugin to handle this issue in a per domain fashion

it is called domain_tos plugin and works like the cacheurl plugin, where admin 
can set 3 parameters at domain_tos.config file:

Example of domain_tos.config:

# Format: [regex for domain] [tos_if_miss] [tos_if_hit]
# desidered tos_if_miss, tos_if_hit should be multiplied by 4 (TOS)
# values equal 0 does not alter the native DSCP field value

# QoS for social networks - DSCP 2(miss) 3(hit) 
http://.*\.facebook\.com 8 12
http://.*\.fbcdn\.net 8 12
http://plus\.google\.com 8 12

# QoS for porn hosts - DSCP 4 (miss) 5(hit) 
http://.*(xvideos|redtube|porn) 18 20

#  QoS for others domains DSCP 0(miss) 1(hit)
http://.* 0 4





 TOS (DSCP) 
 ---

 Key: TS-2644
 URL: https://issues.apache.org/jira/browse/TS-2644
 Project: Traffic Server
  Issue Type: New Feature
  Components: Cache, Network
Reporter: Faysal Banna
 Fix For: sometime


 Hi Guys 
 I wonder if it would be possible to have a plugin that we can assign TOS/DSCP 
 bits to the objects that are being a cache HIT or maybe object type of 
 video/audio. 
 such a plugin would give us better performance and control on how to 
 distribute the output of the cache towards clients. 
 example : 
 suppose i set traffic to clients each of different bandwidth. 
 on a router on a link somewhere on some roof top building i can say this 
 client can get miss object traffic of 512Kbit/s and 1Mbit/s of Hits from the 
 cache. 
 this way if this client is getting a cached object he would get it in 1Mbit/s 
 while his non cached requests would be of 512Kbit/s 
 hope whoever does this patch plugin takes into consideration the mime type or 
 url of the object being retrieved maybe i want to set audio/video being 
 cached or not to have 768Kbit/s while windows updates and android/iphone apps 
 should take no more than 512kbit/s 
 bear in mind that this has nothing to do with Origin servers throttling 
 feature request. this is just client side feature set. 
 much regards 
 Faysal Banna



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Comment Edited] (TS-2644) TOS (DSCP)

2014-04-26 Thread Jay Tomolek (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13982100#comment-13982100
 ] 

Jay Tomolek edited comment on TS-2644 at 4/26/14 8:48 PM:
--

hi guys,
i coded in the past a plugin to handle this issue in a per domain fashion

it is called domain_tos plugin and works like the cacheurl plugin, where admin 
can set 3 parameters at domain_tos.config file:

\# Format: [regex for domain] [tos_if_miss] [tos_if_hit]
\# desidered tos_if_miss, tos_if_hit should be multiplied by 4 (TOS)
\# values equal 0 does not alter the native DSCP field value

## QoS for social networks - DSCP 2(miss) 3(hit) 
http://.*\.facebook\.com 8 12
http://.*\.fbcdn\.net 8 12
http://plus\.google\.com 8 12

## QoS for porn hosts - DSCP 4 (miss) 5(hit) 
http://.*(xvideos|redtube|porn) 18 20

##  QoS for others domains DSCP 0(miss) 1(hit)
http://.* 0 4






was (Author: jaytomolek):
hi guys,
i coded in the past a plugin to handle this issue in a per domain fashion

it is called domain_tos plugin and works like the cacheurl plugin, where admin 
can set 3 parameters at domain_tos.config file:

## Format: [regex for domain] [tos_if_miss] [tos_if_hit]
## desidered tos_if_miss, tos_if_hit should be multiplied by 4 (TOS)
## values equal 0 does not alter the native DSCP field value

## QoS for social networks - DSCP 2(miss) 3(hit) 
http://.*\.facebook\.com 8 12
http://.*\.fbcdn\.net 8 12
http://plus\.google\.com 8 12

## QoS for porn hosts - DSCP 4 (miss) 5(hit) 
http://.*(xvideos|redtube|porn) 18 20

##  QoS for others domains DSCP 0(miss) 1(hit)
http://.* 0 4





 TOS (DSCP) 
 ---

 Key: TS-2644
 URL: https://issues.apache.org/jira/browse/TS-2644
 Project: Traffic Server
  Issue Type: New Feature
  Components: Cache, Network
Reporter: Faysal Banna
 Fix For: sometime


 Hi Guys 
 I wonder if it would be possible to have a plugin that we can assign TOS/DSCP 
 bits to the objects that are being a cache HIT or maybe object type of 
 video/audio. 
 such a plugin would give us better performance and control on how to 
 distribute the output of the cache towards clients. 
 example : 
 suppose i set traffic to clients each of different bandwidth. 
 on a router on a link somewhere on some roof top building i can say this 
 client can get miss object traffic of 512Kbit/s and 1Mbit/s of Hits from the 
 cache. 
 this way if this client is getting a cached object he would get it in 1Mbit/s 
 while his non cached requests would be of 512Kbit/s 
 hope whoever does this patch plugin takes into consideration the mime type or 
 url of the object being retrieved maybe i want to set audio/video being 
 cached or not to have 768Kbit/s while windows updates and android/iphone apps 
 should take no more than 512kbit/s 
 bear in mind that this has nothing to do with Origin servers throttling 
 feature request. this is just client side feature set. 
 much regards 
 Faysal Banna



--
This message was sent by Atlassian JIRA
(v6.2#6252)