RE: draft-santitoro-rap-policy-errorcodes-01.txt

[Yoram Bernet <yoramb@microsoft.com>]

> Ok. I think the good thing is that I'm more comfortable 
> thinking that this 
> draft deserves to be a WG item. So my vote is yes on this issue.
> 

Great - i'm looking forward to getting some broader discussion around this. 

> Short answers to the points you raised:
> 
> >First of all - it largely removes the incentive for an 
> application to be
> >well-behaved. If the application is not upgraded, it at 
> least gets to try to
> >get service. If it's upgraded - it gets completely denied. 
> Why should an
> >application upgrade?
> 
> The application is upgraded because the customers (the network 
> administrator) asks for a better control over the send/do-not-send 
> behavior. Being able to send unwanted flows is not a benefit.
> 

I think that we have a different view of the way applications are written.
To the network manager an application 'being able to send unwanted flows' is
ceretainly not a benefit. However, to the application writer and to the
user, every flow is 'wanted'. In certain cases, there will be a feedback
loop of app writer misbehaves, therefore net manager refuses to deploy. In
other cases, the net manager will have the ability to do some form of
traffic separation, that is aided by the signaling and identification from
the host. In these cases, it's just fine for apps to send even if they don't
'get qos'. The net manager will just downgrade their priority. So - these
flows are tolerated but not wanted. The spectrum of possibilities is a
littel overwhelming to me - so - I realize that my views here may not be
correct or even entirely self-consistent, but - i'm not yet convinced that
they are entirely wrong either. This is where I think we need to hear more
opinions and to sit face to face and sketch some of the different
possibilities.

> >Second - if you have the means in the network to provide 
> traffic separation,
> >then you should apply this means regardless of what the app 
> says or does not
> >say it will do. In other words - the signaling provides you with the
> >classification information that you need to recognize the 
> flow of interest.
> >If you have the ability to use this classification info to 
> downgrade the
> >priority of the traffic in the WAN, then you should do so - 
> regardless. Thus
> >- your behaviour would not change because the app claims to 
> be well behaved.
> 
> Two points here.
> 
> First, I might not have traffic separation, but use the LBE 
> marking to 
> control the application flow using a policer/shaper on the 
> WAN edge in the 
> form of if (LBE) limit flows to x.

When I said 'having the means in the network to provide traffic separation',
I did not distinguish between the WAN edge or the core. Traffic separation
in the network is traffic separation in the network, wherever it is done.

> Second, Providing LBE to the application means that I want to let the 
> application try and run even if I'm sure I'm not going to 
> provide it with 
> the appropriate QoS. Suppose my experience tell me that these 
> application 
> doesn't work in such situation, making the persons using them 
> to conclude 
> that either 'the network is not operating as should' or 'the 
> application is 
> worthless'. I want to be sure that if there is no room for 
> the application, 
> it will not send traffic. In this case, I want to return a don't send 
> indication instead of an LBE decision.
> 

I'm all for offering this kind of functionality. However, the greatest
flexibility arises when there are the means to accommodate both apps that
can use lbe as well as apps that do not. In many cases, app writers may
defer this decision to the user: Dear user - you have noit been granted the
service you asked for. Would you like to continue anyway? If so - don't
complain about the service. If not - you may hang up and try your call again
later.

> >The application may or may not know this. For example - an 
> application might
> >(in response to failed admission control, but not the 'do 
> not send' message)
> >defer to the user, with a UI of the form: "You will not be 
> granted QoS for
> >this session. You may: 1) try your call again later 2) 
> proceed with no qos
> >3) retry with a lesser codec (e.g. press the 56 Kbps button 
> instead of the
> >T-1 button).
> 
> Good example. There are several options for doing that, the 
> cleanest is:
> 
> The application is going to wait for a successful Resv, 
> otherwise it can 
> not prompt the users with the options upon admission failure. 
> Therefore it 
> should indicate this in the initial Path message exchange.

Why?
 
> The application 
> might get a don't send indication. It might get admission 
> error only. When 
> this happens the user is prompted to answer. If he chooses 3, 
> you resend a 
> new Path message with the new TSPEC right? So do the same if 
> he chooses 
> option 2 and resend a Path with the indication that the 
> application IS 
> going to send now without regard for the final answer. This 
> is how a 'good 
> application' should behave.

I guess I just don't agree that one can expect all applications to behave in
this manner.

> Note that this does not mean that 
> you have to 
> wait now for the successful Resv therefore it doesn't add any 
> additional 
> delay on the application.
> 
> Regards
> Ron
> 
Regards,
Yoram