Subject: RE: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la rge?

From: "Elwell, John" <[email-masked]>
Date: Wed, 04 Apr 2007 07:21:27 +0100

Dan,
 
You are right, of course, and I wasn't necessarily thinking about
standardising a value of N. But let's have some idea what value of N we are
aiming it. If we consider this value of N to be a huge burden on the
significant population of UACs when an INVITE request is forked, then we
need to rethink the solution. So maybe would need a recommendation that
forked INVITE requests be used only up to a certain number of appearances
and look for alternative solutions to cover any situations with a much
larger number of appearances.
 
I would be interested to know whether there is any information from SIPit
concerning the ability of UACs to cope with INVITE requests that get forked
to a large number of UASs and the degree to which this is impacted by ICE,
key management, etc.
 
John

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: 04 April 2007 03:26
To: Elwell, John
Cc: [email-masked]; [email-masked]
Subject: RE: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la
rge?

So how do we get to "N"?  What factors need to be considered in arriving at
that number? 
  - whether ICE or key management is involved? 
  - capabilities of the UAC initiating the call? 
  - bandwidth on either end?  (latency?) 
  - capabilities of intermediary SIP proxy servers?  (or SBCs or firewalls?)

  - ?? 

Given the number of possible network permutations, I wonder if we can get to
a hard number... or if it is more of a sliding scale based on capabilities,
i.e. if ICE is involved N = x, if ICE is not involved N = y.  If it's a
sliding scale, it raises the question to me of whether this is something
that can truly be standardized, or if it is more something for a BCP or some
form of engineering guidelines. 

My 2 cents, 
Dan 

-- 
Dan York, CISSP
Dir of IP Technology, Office of the CTO
Mitel       http://www.mitel.com
[email-masked] +1-613-592-2122
PGP key (F7E3C3B4) available for 
secure communication

	"Elwell, John" <[email-masked]> 

04/03/2007 02:49 AM 

        To:        [email-masked], [email-masked] 
        cc:         
        Subject:        RE: [BLISS] draft-johnston-bliss-mla-req-00.txt -
how large is la        rge?

Exactly, we really must identify some sort of limit to N, where N is the
number of UAs to which an INVITE request is forked. It is not just the large
number of early dialogs, but the possible need to do ICE checks and key
management calculations on each of these. The UAC has no control over the
degree of parallel forking. A UAC deployed in a home, say, cannot be
expected to cater for large values of N when it calls into an enterprise
that has this type of arrangement.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: 02 April 2007 21:45
> To: [email-masked]
> Subject: [BLISS] draft-johnston-bliss-mla-req-00.txt - how 
> large is large?
> 
> One aspect of this problem that may need to be addressed is whether an
> incoming call is expected to be presented on all appearances of the
> DN.  For a key system, people expect that.  But a key system usually
> has less than a dozen stations.  If we expect a DN to appear on more
> than 10 UAs, various scaling problems show up.  E.g., consider the
> hospital system that Geoff Devine described with 192 appearances of
> each of 16 lines.  If an incoming call rings on all 192 appearances,
> the calling UA will see 192 early dialogs!
> 
> OTOH, if we want to restrict the number of forks of an incoming call,
> how is the proxy to decide which UAs should see that call?
> 
> Dale
> 
> _______________________________________________
> BLISS mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/bliss
> 

_______________________________________________
BLISS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bliss

_______________________________________________
BLISS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bliss

---

From: Alan Johnston <[email-masked]>
Date: Wed, 04 Apr 2007 10:56:15 -0500

We will include a discussion of these issues in the next version.  We 
will also describe how a UA can just subscribe to the Appearance Agent 
but not register against the AOR and make sure there are no issues with 
this mode of operation.

Thanks,
Alan

Elwell, John wrote:
> standardising a value of N. But let's have some idea what value of N 
> we are aiming it. If we consider this value of N to be a huge burden 
> on the significant population of UACs when an INVITE request is 
> forked, then we need to rethink the solution. So maybe would need a 
> recommendation that forked INVITE requests be used only up to a 
> certain number of appearances and look for alternative solutions to 
> cover any situations with a much larger number of appearances.
>  
> I would be interested to know whether there is any information from 
> SIPit concerning the ability of UACs to cope with INVITE requests that 
> get forked to a large number of UASs and the degree to which this is 
> impacted by ICE, key management, etc.
>  
> John
>
>     ------------------------------------------------------------------------
>     *From:* [email-masked] [mailto:[email-masked]]
>     *Sent:* 04 April 2007 03:26
>     *To:* Elwell, John
>     *Cc:* [email-masked]; [email-masked]
>     *Subject:* RE: [BLISS] draft-johnston-bliss-mla-req-00.txt - how
>     large is la rge?
>
>
>     So how do we get to "N"?  What factors need to be considered in
>     arriving at that number?
>     Given the number of possible network permutations, I wonder if we
>     can get to a hard number... or if it is more of a sliding scale
>     based on capabilities, i.e. if ICE is involved N = x, if ICE is
>     not involved N = y.  If it's a sliding scale, it raises the
>     question to me of whether this is something that can truly be
>     standardized, or if it is more something for a BCP or some form of
>     engineering guidelines.
>
>     My 2 cents,
>     Dan
>
>     -- 
>     Dan York, CISSP
>     	*"Elwell, John" <[email-masked]>*
>
>     04/03/2007 02:49 AM
>
>     	       
>             Subject:        RE: [BLISS]
>     draft-johnston-bliss-mla-req-00.txt - how large is la        rge?
>
>
>
>
> ------------------------------------------------------------------------
>

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 05 Apr 2007 17:02:02 -0500

Hi, John,

I may have misunderstood your previous note in this thread, but I thought you were saying that the UAC has no control over what engineering guidelines the UAS decides are appropriate - if my limited-capacity UA calls your massively-forking proxy, something fails, and the UAC has no way to determine what works and what fails.

Or did I miss your point?

Spencer
  ----- Original Message ----- 
  From: Elwell, John 
  To: [email-masked] 
  Cc: [email-masked] 
  Sent: Wednesday, April 04, 2007 1:21 AM
  Subject: RE: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la rge?

  Dan,

  You are right, of course, and I wasn't necessarily thinking about standardising a value of N. But let's have some idea what value of N we are aiming it. If we consider this value of N to be a huge burden on the significant population of UACs when an INVITE request is forked, then we need to rethink the solution. So maybe would need a recommendation that forked INVITE requests be used only up to a certain number of appearances and look for alternative solutions to cover any situations with a much larger number of appearances.

  I would be interested to know whether there is any information from SIPit concerning the ability of UACs to cope with INVITE requests that get forked to a large number of UASs and the degree to which this is impacted by ICE, key management, etc.

  John

----------------------------------------------------------------------------
    From: [email-masked] [mailto:[email-masked]] 
    Sent: 04 April 2007 03:26
    To: Elwell, John
    Cc: [email-masked]; [email-masked]
    Subject: RE: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la rge?

    So how do we get to "N"?  What factors need to be considered in arriving at that number? 

    Given the number of possible network permutations, I wonder if we can get to a hard number... or if it is more of a sliding scale based on capabilities, i.e. if ICE is involved N = x, if ICE is not involved N = y.  If it's a sliding scale, it raises the question to me of whether this is something that can truly be standardized, or if it is more something for a BCP or some form of engineering guidelines. 

    My 2 cents, 
    Dan 

                 
                  To:        [email-masked], [email-masked] 
                  cc:         
                  Subject:        RE: [BLISS] draft-johnston-bliss-mla-req-00.txt - how large is la        rge? 

    John

------------------------------------------------------------------------------