crossbow discuss - Mar 2009 - IPQoS... are we ready to kill it yet?

Now that we''ve got crossbow, is there any remaining need for IPQoS?
Or is it necessary to wait for future crossbow work first?

Darren

On 03/25/09 05:47, Darren Reed wrote:
> Now that we''ve got crossbow, is there any remaining need for
IPQoS?
> Or is it necessary to wait for future crossbow work first?
good question.
Crossbow opted for the speed of parsing and steering packets to flows, 
which necessitates keeping
the flow description rather basic.
We lack some of the features of ipqos, such as the support of port 
ranges for instance, or more combinations of flow selectors.
On the policy side, ipcosconf (at least on paper) expresses property 
like committed burst, peak_burst, etc
which are currently not yet offered by crossbow.

The interesting question to both aliases is how much of the missing 
features is really still in use

    Kais
>
> Darren
>
> _______________________________________________
> networking-discuss mailing list
> networking-discuss at opensolaris.org
>

On Tue, 2009-03-31 at 12:23 -0700, Kais Belgaied wrote:
> On 03/25/09 05:47, Darren Reed wrote:
> > Now that we''ve got crossbow, is there any remaining need for
IPQoS?
> > Or is it necessary to wait for future crossbow work first?
> 
> good question.
> Crossbow opted for the speed of parsing and steering packets to flows, 
> which necessitates keeping
> the flow description rather basic.
> We lack some of the features of ipqos, such as the support of port 
> ranges for instance, or more combinations of flow selectors.
> On the policy side, ipcosconf (at least on paper) expresses property 
> like committed burst, peak_burst, etc
> which are currently not yet offered by crossbow.
There is also the tagging of outgoing packets with VLAN priority tags.
I don''t know how widely used that is, though.

-Seb

On Mar 31, 2009, at 3:36 PM, Sebastien Roy wrote:
>
> On Tue, 2009-03-31 at 12:23 -0700, Kais Belgaied wrote:
>> On 03/25/09 05:47, Darren Reed wrote:
>>> Now that we''ve got crossbow, is there any remaining need
for IPQoS?
>>> Or is it necessary to wait for future crossbow work first?
>>
>> good question.
>> Crossbow opted for the speed of parsing and steering packets to  
>> flows,
>> which necessitates keeping
>> the flow description rather basic.
>> We lack some of the features of ipqos, such as the support of port
>> ranges for instance, or more combinations of flow selectors.
>> On the policy side, ipcosconf (at least on paper) expresses property
>> like committed burst, peak_burst, etc
>> which are currently not yet offered by crossbow.
>
> There is also the tagging of outgoing packets with VLAN priority tags.
> I don''t know how widely used that is, though.
A lot of switches out there support CoS, and some of those (Juniper,  
namely) have CoS observation "on" by default, but with neutral  
classifications (everything''s the same).

/dale, who has taken a crash-course on this subject recently due to  
CoS interface flags being mysteriously turned on with current s10  
kernel patches :/

On 03/31/09 22:25, Dale Ghent wrote:
> On Mar 31, 2009, at 3:36 PM, Sebastien Roy wrote:
>
>>
>> On Tue, 2009-03-31 at 12:23 -0700, Kais Belgaied wrote:
>>> On 03/25/09 05:47, Darren Reed wrote:
>>>> Now that we''ve got crossbow, is there any remaining
need for IPQoS?
>>>> Or is it necessary to wait for future crossbow work first?
>>>
>>> good question.
>>> Crossbow opted for the speed of parsing and steering packets to
flows,
>>> which necessitates keeping
>>> the flow description rather basic.
>>> We lack some of the features of ipqos, such as the support of port
>>> ranges for instance, or more combinations of flow selectors.
>>> On the policy side, ipcosconf (at least on paper) expresses
property
>>> like committed burst, peak_burst, etc
>>> which are currently not yet offered by crossbow.
>>
>> There is also the tagging of outgoing packets with VLAN priority tags.
>> I don''t know how widely used that is, though.
yep. The support of DSCP tagging had to be delayed in the first phase of 
Crossbow. It need to be finished.
>
> A lot of switches out there support CoS, and some of those (Juniper, 
> namely) have CoS observation "on" by default, but with neutral 
> classifications (everything''s the same).
good to know.

Kais.
>
> /dale, who has taken a crash-course on this subject recently due to 
> CoS interface flags being mysteriously turned on with current s10 
> kernel patches :/
>

Kais Belgaied wrote:
> On 03/31/09 22:25, Dale Ghent wrote:
>> On Mar 31, 2009, at 3:36 PM, Sebastien Roy wrote:
>>
>>>
>>> On Tue, 2009-03-31 at 12:23 -0700, Kais Belgaied wrote:
>>>> On 03/25/09 05:47, Darren Reed wrote:
>>>>> Now that we''ve got crossbow, is there any
remaining need for IPQoS?
>>>>> Or is it necessary to wait for future crossbow work first?
>>>>
>>>> good question.
>>>> Crossbow opted for the speed of parsing and steering packets to
flows,
>>>> which necessitates keeping
>>>> the flow description rather basic.
>>>> We lack some of the features of ipqos, such as the support of
port
>>>> ranges for instance, or more combinations of flow selectors.
>>>> On the policy side, ipcosconf (at least on paper) expresses
property
>>>> like committed burst, peak_burst, etc
>>>> which are currently not yet offered by crossbow.
>>>
>>> There is also the tagging of outgoing packets with VLAN priority
tags.
>>> I don''t know how widely used that is, though.
>
> yep. The support of DSCP tagging had to be delayed in the first phase 
> of Crossbow. It need to be finished.
In my opinion, this would be a pre-requisite for removal of the IPQoS.  
Unless you can somehow prove that nobody is using IPQoS in this manner...

    -- Garrett