Subject: [martini] #2: Scaling to Several Thousand Assigned Telephone Numbers

From: "martini issue tracker" <[email-masked]>
Date: Sat, 20 Feb 2010 05:23:34 -0000

#2: Scaling to Several Thousand Assigned Telephone Numbers
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:  john.elwell@…                     
     Type:  defect                     |      Status:  new                               
 Priority:  major                      |   Milestone:  milestone1                        
Component:  reqs                       |     Version:  1.0                               
 Severity:  In WG Last Call            |    Keywords:                                    
---------------------------------------+------------------------------------
 Section 5

    DES2 - The mechanism SHOULD scale to SIP-PBXs of several thousand
    assigned telephone numbers.

 [BA] Do we really think that the MARTINI mechanism will be used to
 register several thousand AORs??  I had thought that is mechanism is most
 likely to appeal to small businesses or branch offices with a modest
 number of extensions (e.g. typically a few hundred at most).

 Recommending that the mechanism work with several thousand AORs has
 implications for issues such as request or response fragmentation, SIP
 message size, etc.  So before putting in a requirement like this (even if
 it is only desirable), I'd like to see concrete evidence that there are
 real customers out there who both might
 use it that way, and have good reasons to do so (e.g. there is a good
 reason why they can't use RFC 3263 domain routing instead with a static or
 even a dynamically assigned address and dynamic DNS).

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/2>
martini <http://tools.ietf.org/martini/>

---

From: "Richard Shockey" <[email-masked]>
Date: Sat, 20 Feb 2010 09:50:24 -0500

I think this requirement can safely be removed. The vast majority of installations I'm aware of that use Implicit Registration are typically sub 24 CUA's in the single site SMB market.

 Section 5

_______________________________________________
martini mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/martini

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 22 Feb 2010 09:59:47 +0100

Yes, there was some discussion on this way back, and I guess there was not clear consensus. I think Spencer suggested it should be removed and Jack wanted to retain it, so it stayed. I don't know if anyone else spoke for or against.

I believe there should be some sort of figure given here as a desirable target, but "several thousand" might be too high. Clearly a solution that scales only to 10 AORs, say, would not be adequate.

John

> -----Original Message-----
> From: martini issue tracker [mailto:[email-masked]] 
> Sent: 20 February 2010 05:24
> To: Elwell, John; [email-masked]
> Cc: [email-masked]
> Subject: [martini] #2: Scaling to Several Thousand Assigned 
> Telephone Numbers
> 
>  Reporter:  bernard_aboba@...            |       Owner:  
> john.elwell@...

---

From: "Jack Burton" <[email-masked]>
Date: Mon, 22 Feb 2010 11:23:56 -0500

John,
 
I misunderstood the requirement when I made the comment desiring retention.  (I was thinking several thousand endpoints among all customers, not behind a single PBX).
 
I am OK with its deletion.
 
-Jack

>>> "Elwell, John" <[email-masked]> 2/22/2010 03:59 >>>

John

-------------------------------------------------------- 
The information transmitted in this email and any of its attachments is intended only for the person or entity to which it is addressed and may contain information concerning Cablevision and/or its affiliates and subsidiaries that is proprietary, privileged, confidential and/or subject to copyright.   Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient(s) is prohibited and may be unlawful.  If you received this in error, please contact the sender immediately and delete and destroy the communication and all of the attachments you have received and all copies thereof.
--------------------------------------------------------

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 22 Feb 2010 10:59:17 -0600

(speaking as co-chair)

> Yes, there was some discussion on this way back, and I guess there was not 
> clear consensus. I think Spencer suggested it should be removed and Jack 
> wanted to retain it, so it stayed. I don't know if anyone else spoke for 
> or against.
>
> I believe there should be some sort of figure given here as a desirable 
> target, but "several thousand" might be too high. Clearly a solution that 
> scales only to 10 AORs, say, would not be adequate.

Just to explicitly state where I'm coming from...

I don't care (as participant) whether we have a requirement like this. Since 
we have one now, and are discussing technical issues based on that 
requirement, I'm fairly sure that just deleting the requirement is not the 
right thing to do - the first time someone uses MARTINI to mass-register 
several thousand AoRs and it doesn't work, this will still be a technical 
issue.

What I would like to do is to avoid the situation where we get to IETF Last 
Call and get review comments that ask nosy questions like, "so, I see that 
this request (or response, doesn't matter) can carry several thousand AoRs. 
Let's pretend that each AoR is 10 bytes long. What's your story for IP 
fragmentation? What's your story for intermediate devices that might not 
expect REGISTER request/responses that are that big?", and go down the 
rabbit hole about whether TCP fallback is realistic, etc.

We've played out discussions like that on this list already, and that's 
before the INT and TSV guys got hold of the specifications, which would 
happen at IETF Last Call/IESG Evaluation time. I'm not saying that we 
couldn't force that through, I'm saying that we're trying to converge 
quickly, and ignoring known open technical issues isn't the fast path to 
IETF consensus.

If we keep this requirement, I see a few paths forward.

(a) We can ignore the likelihood that this will be noticed and discussed 
(and perhaps even DISCUSSed, in the IESG balloting sense).

(b) We can try to figure out how we would carry several thousand 10-byte 
AoRs, and include that in the solutions spec (whether range encoding, byte 
compression, or some other clever plan).

(c) We can submit a solutions draft that supports a specific number of AoRs 
without the enhanced encoding/compression mechanisms, and say "this will 
work in all reasonable deployments, even with UDP as transport".

(d) We can submit a draft that says "note that MARTINI REGISTER 
request/responses will be bigger than ordinary REGISTER request/responses, 
based on the number of AoRs that you're mass-registering. If you start 
having problems because of the increased size, here are some things that you 
should do".

Are there other alterntives I'm missing?

I'd prefer not to do (a), because we're trying to converge quickly, and 
ignoring technical concerns that have already been raised is just shooting 
ourselves in the foot from an IETF process perspective. If Bernard and I 
make the decision to request publication with known technical issues, 
someone should appeal that decision. Even if you don't, we'll still have 
long discussions outside the working group that we're trying to avoid.

(b) would be lovely if we can come up with a story quickly. If you agree 
with this alternative, please send text that takes account the Gospel 
according to Shockey ("number ranges fragment").

(c) isn't likely to give us "several thousand AoRs". Dean did helpful math 
which was more scientific than my back-of-the-envelope (see 
http://www.ietf.org/mail-archive/web/martini/current/msg00833.html), and 
came up with 70. That's more than an order of magnitude less than the 
requirement requires, and (unfortunately) it may be optimistic outside North 
America, where AoRs can be longer than 10 digits.

(d) would be OK with me if we can (1) agree on some reasonable mitigations 
("if TCP doesn't work on the path to your SP, you need to make it work"), 
and (2) include a bailout, which is probably something like "if you have 
tried all the successful mitigations and still can't use MARTINI, either get 
another SP or get a domain and start using RFC 3263". Again, if you agree 
with this alternative, please send text.

Thanks,

Spencer, as co-chair

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 22 Feb 2010 18:07:57 +0100

Whether the IP-PBX is attached to a subscription type approach as in MARTINI, or whether it is allowed to peer with the other network in a more normal fashion seems to be at the whim of the service provider, rather than dependent on the size of the IPPBX. Some service providers will provide both mechanisms. Some others may adopt only the MARTINI approach because it suits their approach to maintaining customer subscriptions.

As such the MARTINI approach has to cater for all sizes of PBX that could want to use an SSP. Generally the largest PBXs tend to be around 2500 to 5000 lines (there are bigger deployments out there - but in those cases they seem to be fulfilling the role of an SSP in their own right.

regards

Keith 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of martini issue tracker
> Sent: Saturday, February 20, 2010 5:24 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> ---------------------------------------+----------------------
> ----------
> ---------------------------------------+----
> ---------------------------------------+----------------------
> ----------
> ---------------------------------------+----
>  Section 5
> 
>  [BA] Do we really think that the MARTINI mechanism will be 
> used to  register several thousand AORs??  I had thought that 
> is mechanism is most  likely to appeal to small businesses or 
> branch offices with a modest  number of extensions (e.g. 
> typically a few hundred at most).
> 
>  Recommending that the mechanism work with several thousand 
> AORs has  implications for issues such as request or response 
> fragmentation, SIP  message size, etc.  So before putting in 
> a requirement like this (even if  it is only desirable), I'd 
> like to see concrete evidence that there are  real customers 
> out there who both might  use it that way, and have good 
> reasons to do so (e.g. there is a good  reason why they can't 
> use RFC 3263 domain routing instead with a static or  even a 
> dynamically assigned address and dynamic DNS).
> 
> --

---

From: "Brian Lindsay" <[email-masked]>
Date: Mon, 22 Feb 2010 12:17:50 -0500

Hi Spencer,

   Regarding "Are there other alterntives I'm missing?", there is an
option (e) in which is the MARTINI register transaction doesn't contain
the associated E.164 numbers. The MARTINI mechanism has no scalability
issue in that case.

   Thanks
      Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Spencer Dawkins
Sent: Monday, February 22, 2010 11:59 AM
To: Elwell, John; [email-masked]
Subject: Re: [martini] #2: Scaling to Several Thousand Assigned
TelephoneNumbers

(speaking as co-chair)

> Yes, there was some discussion on this way back, and I guess there was

> not clear consensus. I think Spencer suggested it should be removed 
> and Jack wanted to retain it, so it stayed. I don't know if anyone 
> else spoke for or against.
>
> I believe there should be some sort of figure given here as a 
> desirable target, but "several thousand" might be too high. Clearly a 
> solution that scales only to 10 AORs, say, would not be adequate.

I don't care (as participant) whether we have a requirement like this.
Since we have one now, and are discussing technical issues based on that
requirement, I'm fairly sure that just deleting the requirement is not
the right thing to do - the first time someone uses MARTINI to
mass-register several thousand AoRs and it doesn't work, this will still
be a technical issue.

What I would like to do is to avoid the situation where we get to IETF
Last Call and get review comments that ask nosy questions like, "so, I
see that this request (or response, doesn't matter) can carry several
thousand AoRs. 
Let's pretend that each AoR is 10 bytes long. What's your story for IP
fragmentation? What's your story for intermediate devices that might not
expect REGISTER request/responses that are that big?", and go down the
rabbit hole about whether TCP fallback is realistic, etc.

(b) We can try to figure out how we would carry several thousand 10-byte
AoRs, and include that in the solutions spec (whether range encoding,
byte compression, or some other clever plan).

(c) We can submit a solutions draft that supports a specific number of
AoRs without the enhanced encoding/compression mechanisms, and say "this
will work in all reasonable deployments, even with UDP as transport".

(d) We can submit a draft that says "note that MARTINI REGISTER
request/responses will be bigger than ordinary REGISTER
request/responses, based on the number of AoRs that you're
mass-registering. If you start having problems because of the increased
size, here are some things that you should do".

I'd prefer not to do (a), because we're trying to converge quickly, and
ignoring technical concerns that have already been raised is just
shooting ourselves in the foot from an IETF process perspective. If
Bernard and I make the decision to request publication with known
technical issues, someone should appeal that decision. Even if you
don't, we'll still have long discussions outside the working group that
we're trying to avoid.

(c) isn't likely to give us "several thousand AoRs". Dean did helpful
math which was more scientific than my back-of-the-envelope (see
http://www.ietf.org/mail-archive/web/martini/current/msg00833.html), and
came up with 70. That's more than an order of magnitude less than the
requirement requires, and (unfortunately) it may be optimistic outside
North America, where AoRs can be longer than 10 digits.

(d) would be OK with me if we can (1) agree on some reasonable
mitigations ("if TCP doesn't work on the path to your SP, you need to
make it work"), and (2) include a bailout, which is probably something
like "if you have tried all the successful mitigations and still can't
use MARTINI, either get another SP or get a domain and start using RFC
3263". Again, if you agree with this alternative, please send text.

Thanks,

Spencer, as co-chair

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 22 Feb 2010 18:31:47 +0100

That is because the market has the vast majority of PBXx in that size.

50% of the market is below 100 lines. 

So where do you put the break point? You have not made any technical argument for excluding any size of PBX, merely said that most PBXs are small.

Keith 

> [mailto:[email-masked]] On Behalf Of Richard Shockey
> Sent: Saturday, February 20, 2010 2:50 PM
> To: 'MARTINI'
> Subject: Re: [martini] #2: Scaling to Several Thousand 
> Assigned Telephone Numbers
> 
> I think this requirement can safely be removed. The vast 
> majority of installations I'm aware of that use Implicit 
> Registration are typically sub 24 CUA's in the single site SMB market.
> 
> 
> 
>  Section 5
>

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 22 Feb 2010 18:35:04 +0100

Spencer, 

> From: Spencer Dawkins [mailto:[email-masked]] 
> Sent: 22 February 2010 16:59
[JRE] Whilst the chances of picking on this at IETF last call might be reduced if we don't explicitly mention a requirement, I don't think we can ignore that possibility. The idea is to try to cover everything before we get to that stage, to minimise the risk at IETF last call.

> request/responses, 
[JRE] The one path you don't mention is having a solution that does not involve conveying the list of AORs in a SIP message, and this comes down to the discussion whether there is a need for an intermediary to know the list of currently registered AORs.

> long discussions outside the working group that we're trying to avoid.
[JRE] I agree, but just omitting to state a requirement on number of AORs does not necessarily prevent a DISCUSS.

> according to Shockey ("number ranges fragment").
[JRE] I guess one possibility is draft-roach-http-subscribe, where anyone wishing to find out the list of AORs currently registered can use HTTP(S) and can receive a NOTIFY request if the list changes (telling you to go do another GET). I am not suggesting MARTINI should specify this, but it would be our answer.

> America, where AoRs can be longer than 10 digits.
[JRE] I don't think that we can have a solution that limits you to 70 (or less outside NA) AORs. This is true whether or not we have an explicit requirement for a higher number.

> with this alternative, please send text.
[JRE] Or use non-MARTINI means to obtain the list of AORs as a possible mitigation (e.g., HTTP(S) + draft-roach-http-subscribe).

John (as individual)

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 22 Feb 2010 18:36:00 +0100

Thanks, you beat me to it.

John

> From: Brian Lindsay [mailto:[email-masked]] 
> Sent: 22 February 2010 17:18
> To: Spencer Dawkins; Elwell, John; [email-masked]
> Subject: RE: [martini] #2: Scaling to Several Thousand 
> Assigned TelephoneNumbers
> 
>  Hi Spencer,
>