Subject: RE: [Sip] Manyfolks: Unified local/remote model

From: "Christian Huitema" <[email-masked]>
Date: Mon, 25 Mar 2002 10:03:20 -0800

> The problem with your suggestion is that the offerer specifies what he
> will do, not what he wants. For instance, if the offerer says
"remote",
> it means (in your model) that he will perform resource reservations in
> the answerer's access network. But what we really want to say is: I
want
> QoS in your access network. Do whatever to ensure that.

The problem with QoS signaling is that it may or may not reflect any
change of state in the network. The only way to be sure that there is
available bandwidth is to perform a continuity test -- and even that
will only give us an "instant snapshot", rather than a guarantee that
the bw will still be available in the future.

In fact, the continuity test would be very useful in many scenarios,
regardless of QoS. In today's world of firewalls and NATs, I can see
many cases in which two parties successfully negotiate codecs and other
SDP parameters, and then find out that they cannot actually communicate.
The same considerations that drove the DCS effort apply: we should
perform an RTP continuity test before ringing the called party...

-- Christian Huitema

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Alan O'Neill" <[email-masked]>
Date: Tue, 26 Mar 2002 01:38:50 -0500

My problem is exactly that, which is that it is 3G and DCS specific with
lots of assumptions about these deployments thrown in. I do not believe it
adequately deals with the rest of the existing Internet, nor between the
three of them. I also do not like the fact that e2e and local/remote are
distinct tags, and that significant assumptions are made about what these
tags mean from the specific existing/planned deployments. I specifically
dislike the fact that somehow e2e is being coloured as magic cf segmented. I
can draw scenarios in which both in conjunction with SLAs and Updates
guarantee exactly the same, e2e less or e2e more, as can many on this list I
am sure. Hence my dislike of that particular phrase about segmented which is
frankly incorrect. e2e has advantages and disadvantages wrt segmented in the
areas of overhead, RTTs, required degree of diff-serv dimensioning, levewl
of assurance etc depending on the deployment.

This will force the building of a=des:qos2 tags later on which is a shame
but I guess where we will have to go if you so badly want to get this out of
the door. 

Neither what you are suggesting nor the unified approach actually deals with
my longer term company requirements, and what I believe is actually the
general solution anyway but I deliberately avoided throwing that in as that
would have kept us going for months. I am only seeking the best interim
solution given the available timescales that ensures that future support for
the wider model is possible and that interoperability will be efficient..

Alan.

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]]
Sent: 25 March 2002 18:02
To: Alan O'Neill
Cc: 'David R. Oran '; [email-masked] '
Subject: Re: [Sip] Manyfolks: Unified local/remote model

Hello,

The problem with your suggestion is that the offerer specifies what he
will do, not what he wants. For instance, if the offerer says "remote",
it means (in your model) that he will perform resource reservations in
the answerer's access network. But what we really want to say is: I want
QoS in your access network. Do whatever to ensure that.

You claim that in manyfolks-05 the offerer chooses the status type
(segmented or e2e) and that the answerer cannot change it. This is not a
problem. If I ask for mandatory e2e, I do not want the answerer to
change it to segmented. However, if I ask for segmented and I support
e2e, it will be acceptable for me that the status type is changed from
segmented to e2e. Manyfolks-05 already covers this, since the offerer
will include mandatory local/remote and optional e2e (to indicate
support for the e2e status type). The answerer can upgrade the e2e line
to mandatory, and assume that the local/remote preconditions are met
once the e2e preconditions are met.

Alan, the current manyfolks mechanism is what DCS and 3GPP want.
Everything they need in their call flows is covered by manyfolks-05.
Which is the scenario you have in mind that we do not currently cover?

Thanks,

Gonzalo

Alan O'Neill wrote:
> 
>  Dave,
> 
> Here is one way to view local/remote and e2e which I believe better
supports
> inter-domain preconditions. This is through the removal of the two
distinct
> status types because they are a barrier to efficient offer/answer
> negotiation between heterogeneous domains, specifically because you need
to
> use a new offer if a UA starts with the wrong status type. It also
requires
> two sets of processing rules which is unnecessarily complex and avoids the
> e2e v segmented beauty contest..It certainly is not a design though just a
> way to represent the ideas.
> 
> As before, all preconditions should be assumed to be a request for end to
> end resources in the direction indicated by the direction tag. As before
all
> preconditions requests are e2e in nature but the QoS mechanisms supporting
> these may not be. The current status reflects where we are compared to the
> desired status. Offerer offers, the answerer answers, and Update is used
> where necessary for confirmation. Precondition directions as always are
wrt
> to the SDP sender
> 
> But lets instead use nill, local, remote and localremote where localremote
> implies the availability of an end to end QoS protocol. From the view of
two
> UAs, localremote is as much as we can negotiate as neither UA knows
anything
> about the core in reality, even with an end to end protocol.
> 
> The offerer follows manyfolks-05 and selects between nill, local, remote,
> localremote as to its desired status towards meeting preconditions in the
> specific direction.  The answerer can then select from the offered desired
> status and can specifically choose a subset or move from segmented to e2e
> models. This is achieved by both the desired status and strength being
> negotiable with the answerer responding to the offerer.
> 
> Lets assume for direction caller(offerer) to callee(answerer) we have an
> optional precondition.
> 
> caller sends a=des:qos optional X send
> callee sends a=des:qos optional Y recv
> 
> Note that both ends keep there own view of what they have to do to meet
> precondition so offerer/answerer des lines are different in each
direction.
> For below note RSVP is used as one example of a protocol giving
feedback)..
> 
> Actual          Actual
> Offered X               Answered Y              Meaning
> nill                    nill                    Nothing will be booked
>                         local                   Answerer happy to book its
> end
>                         remote          Answerer books other end using
RSVP
> but local RSVP not supported.
>                         localremote             eg e2e via e2e signalling
eg
> RSVP attempted by answerer for both ends
> local                   nill                    Answerer won't book
> anything, offerer can
>                         local                   e2e via segmented model
>                         remote          Answerer will book resources using
> say RSVP
>                         localremote             e2e via e2e signalling eg
> RSVP attempted by answerer for both ends
> remote          nill                    Anwerer won't book anything,left
to
> offerer
>                         local                   Answerer happy to book its
> end
>                         remote          Inverse segmented - each doing
other
> ends QoS (maybe for policy reasons ?)
>                         localremote             e2e via e2e signalling eg
> RSVP attempted by answerer for both ends
> localremote             nill                    Happy for offerer to do
e2e
> via e2e signaling
>                         local                   Switch to segmented model
> with each doing local
>                         remote          switch to inverse segmented model
> (each doing the others end)
>                         localremote             answerer over-rules and
> wishes to book
> 
> Of course the answerer can also respond with 'none' strength to cancel the
> offered precondition, or stengthen it to 'mandatory' to tighten the
> requirement for the desired status for the offerer. The offerers SDP
should
> now reflect the change requested by the answerer and no additional desired
> status negotiation is possible through updates, which only affect current
> status (I think that is optimal)
> 
> Now at this point both ends know what needs to be done, and by whom..If
> offerer is not happy it can re-offer or end the call-leg. Otherwise we
move
> to the current-status aspects...
> 
> The current-status of the offerer will limit the flexibility open to the
> answerer, in its response to the offered desired status, by including
> information indicating that the offerer is starting the booking of, or
> announcing the availability of, resources matching the offerers desired
> status. The answerer should not modify the desired status by contravening
> the current status of the offerer.
> 
> The current status and each end then moves towards the desired status. The
> callee should not alert until the preconditions are met and the caller
> should send an Update when it learns additional information not known to
the
> callee about the current status via changes in its local booking and its
> booking of remote resources, whether as part of a segmented, inverse
> segmented or end to end signalling model.
> 
> I hope I having missed anything and that the addition of an integrated
> local, remote, localremote model eliminates two competing approaches and
the
> risk of the offerer starting with the wrong model. I hope I haven't missed
> anything but this is kin of where I was going with my analysis...
> 
> Alan.
> 
> ----------------------------------------------------------------
> Notice Regarding Intellectual Property Rights
> 
> Flarion's submissions will conform with RFC 2026.  Flarion may seek patent
> protection on some or all of the technical information submitted by its
> employees in connection with the IETF's standards process.  If part(s) of
a
> submission by Flarion is (are) included in a standard and Flarion owns
> patent(s) and/or pending patent application(s) that are essential to
> implementation of such included part(s) in said standard, Flarion is
> prepared to grant a license on fair, reasonable, reciprocal (license back)
> and non-discriminatory terms on such included part(s).
> 

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

---

From: "Alan O'Neill" <[email-masked]>
Date: Tue, 26 Mar 2002 01:38:53 -0500

Hello Christian,

I have a lot of sympathy for your position Christian but would in addition
note that only the reach and the stength of the operators SLA with you is
sufficient to potentially avoid the need for the average user to perform
that continuity test.

The QoS SLA is the mechansim by which an operator and its peers within the
SLA reach, is forced to do the right thing from a dimensioning perspective.
The customer buys the SLA strength/reach commensurate with its preferred
level of call blocking, call degradation probability.

In this model, the continuity test is a reactive mechanism as to why I am
having problems rather than front loaded on all call set-ups, the majority
of which will be fine. This also covers the problem of the continuity test
being fine on call-set up but instantaneous conditions changing. 

Alan.

-----Original Message-----
From: Christian Huitema [mailto:[email-masked]]
Sent: 25 March 2002 18:03
To: Gonzalo Camarillo; Alan O'Neill
Cc: David R. Oran ; [email-masked]
Subject: RE: [Sip] Manyfolks: Unified local/remote model

"remote",
want

-- Christian Huitema

---

From: "Alan O'Neill" <[email-masked]>
Date: Wed, 27 Mar 2002 00:11:38 -0500

in-line

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]]
Sent: 26 March 2002 17:21
To: Alan O'Neill
Cc: [email-masked] '
Subject: Re: [Sip] Manyfolks: Unified local/remote model

Hello Alan,

A few clarifications.

1) When you talk about "my design" (which is wrong in your opinion) you
are talking about a mechanism that was designed by a bunch of people
which did not include myself, and was available in the WG for comments
for a long while. The fact that I am the editor now does not make this
draft "my design". It is the design of many people.

AWO> Sure - the reference was wrt to your role as editor thats all. 

2) you claim that I want to "get this out of the door as soon as
possible". This is not the first time that folks in the WG complain
because we try to meet the deadlines. When we were finishing the SIP
spec (bis), folks in the WG also complained... as Jonathan said then, it
is unfair that people within the WG, rather than recognizing the
incredible amount of work, including evenings, nights and weekends, that
we all have put into both bundle 1 and 2, are only complaining about
"our" designs. In order to meet the deadlines, we need commited authors
and also commited reviewers. The fact that folks wait until the end to
throw comments about the whole contents of the draft , is not the
author's fault. The manyfolks mechanism has been available for review a
long time ago already... and the new additions to manyfolks-04 were
discussed in the mailing list a long while before manyfolks-04 was
actually released.

AWO> Gonzalo..The urgency is clear, understood and appreciated by myself and
was why I avoided trying to widen the scope of the work. I have no need or
interest to slow this work down. I spotted some serious problems during the
previous last call and offered to help write a new draft but non-one
contacted me. The 04 version appeared just as I left for a three week round
the world trip that included two US visits, a UK visit, a house purchase in
Aus, a house sale in the UK, a trip to the IEEE and a lot of air-miles. I
responded as soon as I returned to Aus. I can do no more Gonzalo and my
responses are made in an attempt to improve this work.

3) You have already mentioned several times the "beauty contest" between
e2e and segmented. As far as I know, you are the only one saying that
one is better than the other. As I said previously, both have advantages
and disadvantages, and the draft does not state that one is better or
preferrable than the other. Anyway, if you want me to remove the sentece
that troubles you so much (the one that says that the segmented status
type does not say anything about the backbone), I can remove it. It is
only motivational text, and if you feel so unconfortable with the
sentence, I will get rid of it (although I still think that it is a
perfectly OK sentence). Let me know how you want me to proceed on this.

AWO> Removal would be preferred..thankyou.

4) This draft has been around for a long while, and you are throwing
your comments a few days before WGLC is finished (which is alright).
Since it seems that many people in the WG are happy with this solution,
and what you want is a brand new solution, since the current one is
completely useless for your needs, I believe that you should write a
contribution (as you suggested) which will be available for everybody in
the near future. Due to unfortunate time constrains that don't depend on
me, we cannot wait for it before the IESG last call. 

AWO> I started my review/comments as sson as I could at the begining of last
call and they appear to have lasted the length of that last call because we
couldn't get down to specifics and assumptions. Your attempts to redirect me
out of the SIP wg towards QoS working groups, was not healthy in achieving
consensus when I am making informed, if unwelcome comment. The current spec
is not ideal but it is certainly not useless. As a stated in my first e-mail
I think an excellent job has been done by all in the redesign and rewrite
but that there were still issues. The draft scope does not include
everything I think is ultimately needed but that is fine and a natural
evolution. Things move on and new requirements and bugs become clear over
time. But what is in scope and covered should be correct and complete, and
support maximum interoperability and utility.

Anyway, I believe that we are missunderstanding each other. If you want
to discuss any issue related to this mail thread or to this draft, feel
free to give me a call to +1 212 939 7171 (New York time zone). We may
be able to get a better understanding of the problem on the phone than
we have done on the mail so far. If the time difference makes it
impossible for you to call me during office hours, let me know in a
personal mail and I can try to arrange a conference bridge at a suitable
time.

AWO> Thanks Gonzalo..I will give you a call to at least reduce some the
tension that is evident. I am simply trying to help make a better
solution..My comments and our discussion during Last Call will I hope help
with that aim.

Regards, Alan.

Alan O'Neill wrote:
> 
> in-line.
> 
> Gonzalo,
> 
> I'll make this my last one (if you will :-) though given the end of last
> call which I think is appropriate to unburden the list. I'll leave future
> feedback to a new draft (my only reasonable course) in a while which will
> cover more general requirements, the alternative general solution, our
> specific longerterm requirements and feature / efficiency comparisons to
> manyfolks work.
> 
> Good luck with the IESG,
> 
> Regards,  Alan.
> 
> will do, not what he wants.
> 
> AWO> No the offer/answer combination says what each will do whilst the
> offerer says what it is prepared to do. This is fine since the requirement
> is always known and doesn't need to be signalling. "I want 'strength' end
to
> end QoS please for this session in this direction please."
> 
> For instance, if the offerer says "remote",
> AWO> No I say the same thing as you. The offerer is saying I want QoS in
> your access network by virtue of setting a precondition. If the answerer
> can, it will. If it can't the offerer can try to itself. The offerer
saying
> remote can lead to four different answerer responses and four different
sets
> of mechanism by the two endpoints. In eachc ase the response is clear
about
> whether or not an update is needed.
> 
> change it to segmented.
> AWO> You don't want the change because of what these mean in your model,
not
> because of any basic requirement about what we are trying to achieve. The
> requirement for preconditions is always e2e (pointless otherwise
generally)
> so the only thing to resolve is who does what and the resulting
> feedback...The strength indicates what we should do if any QoS mech
fails..
> 
> However, if I ask for segmented and I support
> AWO> Sure so interoperability is obtained by doubling everything up in the
> offer, or by using a subsequent offer. Seems a shame somehow.
> 
> Alan.
>