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

From: Adam Roach <[email-masked]>
Date: Mon, 01 Mar 2010 18:04:01 -0600

On 2/22/10 11:35, Feb 22, Elwell, John wrote:
> From: Spencer Dawkins [mailto:[email-masked]]
>> (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.
>>      
> [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.
>    

To be clear, it's not 70 DIDs. It's 70 discrete _ranges_ of DIDs. 
Depending on level of fragmentation, that could be anywhere from 70 
individual DIDs (if no two numbers are consecutive) to several hundred 
million DIDs.

So I *could* argue that the proposed scheme actually exceeds the 
specified requirement by five orders of magnitude.

But both extremes are ridiculous on their face, and I think portraying 
either extreme as the basis of an argument is a bit disingenuous.

Is the fragmentation issue so profound that we're really going to see 
PBXes with more than 70 contiguous *RANGES* of DIDs? That seems edging 
into the "implausible" area of these two extremes.

/a

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 1 Mar 2010 18:50:45 -0600

Hi, Adam,

I agree that what we're talking about is "ranges".

What I'm most concerned about is the situation where an enterprise ends up 
with an R.164 space that's just a little more segmented today than it was 
yesterday, and things stop working ("oh, NOW you need to start using RFC 
3263, since your REGISTER just failed").

My understanding from people like Richard Shockey is that we're just at the 
beginning of local number portability for Europe in a serious way, for 
example.

I don't know when 70 segments might become a commonly-encountered 
limitation, but I'm thinking that the chances that this will happen get 
greater every year.

The way I was reading the original requirement, all you'd have to do is send 
70 people from corporate headquarters to home offices (so their E.164s 
aren't routed to the PBX any more).  If we're insisting that we support 
support "several thousand" AoRs, I can imagine that happening (I have a 
vivid imagination, but I'm not sure I'm hallucinating yet). I'm pretty sure 
Nortel sent at least that many people to home offices in the Richardson 
campus during the late 1990s (actually, I'm fairly sure it was several 
hundred, out of a site population of several thousand).

But maybe it will never happen ("you could very well be right").

I THINK where we are is that we decided that we're not going to worry about 
this (if you worry about stuff like this, either manage your number ranges 
carefully or start planning your RFC 3263 migration) - Bernard, is that the 
way you're seeing it?

Thanks,

Spencer

>> [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.
>>
>
> So I *could* argue that the proposed scheme actually exceeds the specified 
> requirement by five orders of magnitude.
>
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini

---

From: Adam Roach <[email-masked]>
Date: Mon, 01 Mar 2010 21:37:43 -0600

On 3/1/10 18:50, Mar 1, Spencer Dawkins wrote:
> What I'm most concerned about is the situation where an enterprise 
> ends up with an R.164 space that's just a little more segmented today 
> than it was yesterday, and things stop working ("oh, NOW you need to 
> start using RFC 3263, since your REGISTER just failed").

I was actually looking more towards RFC 793.

Before people start howling that the vast majority of implementations 
fully ignore the normative requirement to implement TCP, I'll point out 
that none of the "UDP only" (i.e., "we read 3261 except that part") 
implementations that I've ever seen bother counting bytes. Which means 
that they'll happily cobble together a 64 kbyte message and stuff it 
into a UDP packet. And IP takes care of the fragmentation. So it goes 
across the wire in 50-some-odd IP packets. And, for most modern 
networks, that'll work. Maybe not the first time, but it'll work within 
SIP's retransmission window just fine.

Great network design? No, not really. But they ignored some very 
important normative language in RFC 3261. Their bad, their problem. But 
"just failed?" No. That won't happen.

Let's re-run Dean's analysis with this actual reality in mind.

Using Dean's number of about 700 bytes (or so) consumed by a modern 
REGISTER message, that leaves about 64,835 bytes of UDP packet available 
for DIDs. Or approximately 6,483 ranges before things actually "stop 
working."

Which is probably enough.

/a

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 2 Mar 2010 01:56:04 -0600

Hi, Adam,

That would be the right order of magnitude for the requirement we have been 
discussing, so I will check this one off my list of stuff to worry about in 
MARTINI and go on to the next one :D

Thanks,

Spencer

>> What I'm most concerned about is the situation where an enterprise ends 
>> up with an R.164 space that's just a little more segmented today than it 
>> was yesterday, and things stop working ("oh, NOW you need to start using 
>> RFC 3263, since your REGISTER just failed").
>
> that they'll happily cobble together a 64 kbyte message and stuff it into 
> a UDP packet. And IP takes care of the fragmentation. So it goes across 
> the wire in 50-some-odd IP packets. And, for most modern networks, that'll 
> work. Maybe not the first time, but it'll work within SIP's retransmission 
> window just fine.
>
> Great network design? No, not really. But they ignored some very important 
> normative language in RFC 3261. Their bad, their problem. But "just 
> failed?" No. That won't happen.
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 2 Mar 2010 11:36:45 +0100

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adam Roach
> Sent: 02 March 2010 00:04
> To: [email-masked]
> Subject: Re: [martini] #2: Scaling to Several Thousand 
> Assigned Telephone Numbers
> 
> > [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.
> >    
> 
[JRE] I agree we are talking about ranges. My only concern is that people are saying that fragmentation will be a lot more severe in future, as number portability gets going, so in the worst case you could be limited to 70 numbers. Personally I don't mind if MARTINI is restricted to quite small PBXs, and we use RFC 3263 for anything bigger, but I don't think the SSPs want to place the cut-off point as low as 70.

So if we can agree that 70 ranges is sufficient and 70 dicrete numbers is an extreme that we are unlikely to meet in practice, or in the rare case we do we rely on it working through fragmentation or by switching to TCP, that would be OK with me.

So are we moving to a consensus that we should delete DES2, on the basis that it is unrealistic. Or do we need an alternative requirement expressed in number of ranges?

John

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 2 Mar 2010 10:48:51 -0600

Hi, John,

> [JRE] I agree we are talking about ranges. My only concern is that people 
> are saying that fragmentation will be a lot more severe in future, as 
> number portability gets going, so in the worst case you could be limited 
> to 70 numbers. Personally I don't mind if MARTINI is restricted to quite 
> small PBXs, and we use RFC 3263 for anything bigger, but I don't think the 
> SSPs want to place the cut-off point as low as 70.
>
> So if we can agree that 70 ranges is sufficient and 70 dicrete numbers is 
> an extreme that we are unlikely to meet in practice, or in the rare case 
> we do we rely on it working through fragmentation or by switching to TCP, 
> that would be OK with me.
>
> So are we moving to a consensus that we should delete DES2, on the basis 
> that it is unrealistic. Or do we need an alternative requirement expressed 
> in number of ranges?

I understood Adam's note as saying that

- the right answer is to use TCP (as a fallback, at minimum), so we don't 
need to specify a limit.

- if people don't use TCP (at least as a fallback), a larger number of AoR 
(ranges) will probably still work just based on IP fragmentation.

- if this doesn't work (because you punted TCP AND decided to enforce the 
UDP MTU limit), that's your problem to solve, and the suggested answer would 
be to either stop punting TCP or start using RFC 3263.

I think Adam and I broadly agree here, and that no change to the document is 
required.

Does anyone (especially Adam, because I think I'm agreeing with him :-) 
disagree?

Spencer

---

From: Dean Willis <[email-masked]>
Date: Tue, 2 Mar 2010 11:56:30 -0600

On Mar 2, 2010, at 10:48 AM, Spencer Dawkins wrote:
> - the right answer is to use TCP (as a fallback, at minimum), so we  
> don't need to specify a limit.
>
> - if people don't use TCP (at least as a fallback), a larger number  
> of AoR (ranges) will probably still work just based on IP  
> fragmentation.
>
> - if this doesn't work (because you punted TCP AND decided to  
> enforce the UDP MTU limit), that's your problem to solve, and the  
> suggested answer would be to either stop punting TCP or start using  
> RFC 3263.
>
> I think Adam and I broadly agree here, and that no change to the  
> document is required.
>
> Does anyone (especially Adam, because I think I'm agreeing with  
> him :-) disagree?
>

I agree with this set of statements.

However, I will warn us that the "transport police" will probably take  
exception. Congestion-induced retransmission of 64k UDP packets is  
pretty much a text-book example of what they think "harms the Internet".

 From a standards perspective, it would arguably be better to say that  
large registrations MUST be entirely processed over TCP, even though  
we know full well that nobody is going to bother, and that they're  
going to continue with fragmented UDP right until the world's ice caps  
melt from the global warming caused by the excess router-CPU needed to  
process all those retransmitted fragments.

I feel dirty.

--
Dean

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 2 Mar 2010 12:10:59 -0600

I'm sitting in a room with all three TSV ADs now, so I should be able to avoid blindsiding them at IETF Last Call time... but until then - my understanding is that this text in RFC 3261 is overarching:

18.1.1 Sending Requests
   The client side of the transport layer is responsible for sending the
   request and receiving responses.  The user of the transport layer
   passes the client transport the request, an IP address, port,
   transport, and possibly TTL for multicast destinations.

   If a request is within 200 bytes of the path MTU, or if it is larger
   than 1300 bytes and the path MTU is unknown, the request MUST be sent
   using an RFC 2914 [43] congestion controlled transport protocol, such
   as TCP. If this causes a change in the transport protocol from the
   one indicated in the top Via, the value in the top Via MUST be
   changed.  This prevents fragmentation of messages over UDP and
   provides congestion control for larger messages.  However,
   implementations MUST be able to handle messages up to the maximum
   datagram packet size.  For UDP, this size is 65,535 bytes, including
   IP and UDP headers.
If I'm right about that, any conformant implementation will work, and I'm not sure that saying "we really, really mean what RFC 3261 says" is going to change anything that will affect non-conforming implementations.

So, speaking as an individual, I'd say "no change to our document required". Bernard, want to call this one as chair?

Spencer
  ----- Original Message ----- 
  From: Dean Willis 
  To: Spencer Dawkins 
  Cc: Elwell, John ; Adam Roach ; [email-masked] 
  Sent: Tuesday, March 02, 2010 11:56 AM
  Subject: Re: [martini] #2: Scaling to Several Thousand Assigned Telephone Numbers

    - the right answer is to use TCP (as a fallback, at minimum), so we don't need to specify a limit.

    - if people don't use TCP (at least as a fallback), a larger number of AoR (ranges) will probably still work just based on IP fragmentation.

    - if this doesn't work (because you punted TCP AND decided to enforce the UDP MTU limit), that's your problem to solve, and the suggested answer would be to either stop punting TCP or start using RFC 3263.

    I think Adam and I broadly agree here, and that no change to the document is required.

    Does anyone (especially Adam, because I think I'm agreeing with him :-) disagree?

  However, I will warn us that the "transport police" will probably take exception. Congestion-induced retransmission of 64k UDP packets is pretty much a text-book example of what they think "harms the Internet".

  From a standards perspective, it would arguably be better to say that large registrations MUST be entirely processed over TCP, even though we know full well that nobody is going to bother, and that they're going to continue with fragmented UDP right until the world's ice caps melt from the global warming caused by the excess router-CPU needed to process all those retransmitted fragments.

  I feel dirty.

  --
  Dean

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 2 Mar 2010 13:08:43 -0600

Following up on my own post...

I chatted with Lars and with David Harrington (incoming TSV AD, who will be seated before the IESG ballots the requirements draft).

Here's the guidance I got:

- No need to mention this in requirements,

- No need to pick a number of AoR ranges to support,

- Does need to be mentioned in a protocol draft,

- Would be sufficient to point the issue out and say something like "implementations that already violate the "MUST use a congestion-controlled transport such as TCP when sending a request that is large enough to be IP-fragmented" in 3261 may have problems traversing NATs and losing fragmented IP packets when the network is congested; the solution is to use TCP as already required in 3261".

Adam, could you add this to your list for GIN? I can propose more formal text if that's helpful.

Thanks,

Spencer
  ----- Original Message -----  
  From: Spencer Dawkins 
  To: Dean Willis 
  Cc: [email-masked] 
  Sent: Tuesday, March 02, 2010 12:10 PM
  Subject: Re: [martini] #2: Scaling to Several Thousand Assigned TelephoneNumbers

18.1.1 Sending Requests

  Spencer
    ----- Original Message ----- 
    From: Dean Willis 
    To: Spencer Dawkins 
    Cc: Elwell, John ; Adam Roach ; [email-masked] 
    Sent: Tuesday, March 02, 2010 11:56 AM
    Subject: Re: [martini] #2: Scaling to Several Thousand Assigned Telephone Numbers

    I feel dirty.

    --
    Dean

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

---

From: Adam Roach <[email-masked]>
Date: Tue, 02 Mar 2010 13:12:58 -0600

On 3/2/10 11:56, Mar 2, Dean Willis wrote:
>> of AoR (ranges) will probably still work just based on IP fragmentation.
>>
>> - if this doesn't work (because you punted TCP AND decided to enforce 
>> the UDP MTU limit), that's your problem to solve, and the suggested 
>> answer would be to either stop punting TCP or start using RFC 3263.
>>

We're not telling people to do this. There are MUST-strength normative 
statements that tell people *not* to do this, in fact.

But the brain-dead implementations that don't do TCP won't "just break" 
-- as was implied -- when UDP packets start exceeding the MTU. That was 
my point.

/a

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 2 Mar 2010 20:56:47 +0100

So can we close Ticket#2 as "won't fix", i.e., no change to document, scalability desirable remains (and is achievable)? I will do so if no objection today.

John 

> From: Adam Roach [mailto:[email-masked]] 
> Sent: 02 March 2010 19:13
> To: Dean Willis
> Cc: Spencer Dawkins; Elwell, John; [email-masked]
> 		- the right answer is to use TCP (as a 
> fallback, at minimum), so we don't need to specify a limit.
> 		
> 		- if people don't use TCP (at least as a 
> fallback), a larger number of AoR (ranges) will probably 
> still work just based on IP fragmentation.
> 		
> 		- if this doesn't work (because you punted TCP 
> AND decided to enforce the UDP MTU limit), that's your 
> problem to solve, and the suggested answer would be to either 
> stop punting TCP or start using RFC 3263.
> 		
> 	However, I will warn us that the "transport police" 
> will probably take exception. Congestion-induced 
> retransmission of 64k UDP packets is pretty much a text-book 
> example of what they think "harms the Internet".
> 
> 
> We're not telling people to do this. There are MUST-strength 
> normative statements that tell people *not* to do this, in fact.
> 
> But the brain-dead implementations that don't do TCP won't 
> "just break" -- as was implied -- when UDP packets start 
> exceeding the MTU. That was my point.
> 
> /a
> 
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 2 Mar 2010 14:02:06 -0600

Hi, John,

Yes, I agree.

Spencer, as co-chair.

----- Original Message ----- 
From: "Elwell, John" <[email-masked]>
To: "Adam Roach" <[email-masked]>; "Dean Willis" 
<[email-masked]>
Cc: "Spencer Dawkins" <[email-masked]>; <[email-masked]>
Sent: Tuesday, March 02, 2010 1:56 PM
Subject: RE: [martini] #2: Scaling to Several Thousand Assigned Telephone 
Numbers

So can we close Ticket#2 as "won't fix", i.e., no change to document, 
scalability desirable remains (and is achievable)? I will do so if no 
objection today.

John

> =

---

From: Dean Willis <[email-masked]>
Date: Tue, 2 Mar 2010 16:26:44 -0600

On Mar 2, 2010, at 1:12 PM, Adam Roach wrote:

>
>>
>> However, I will warn us that the "transport police" will probably  
>> take exception. Congestion-induced retransmission of 64k UDP  
>> packets is pretty much a text-book example of what they think  
>> "harms the Internet".
>
> But the brain-dead implementations that don't do TCP won't "just  
> break" -- as was implied -- when UDP packets start exceeding the  
> MTU. That was my point.
>

Ok, I'm convinced.

--
Dean

---

From: "martini issue tracker" <[email-masked]>
Date: Wed, 03 Mar 2010 08:14:02 -0000

#2: Scaling to Several Thousand Assigned Telephone Numbers
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:  john.elwell@…                     
     Type:  defect                     |       Status:  closed                            
 Priority:  major                      |    Milestone:  milestone1                        
Component:  reqs                       |      Version:  1.0                               
 Severity:  In WG Last Call            |   Resolution:  wontfix                           
 Keywords:                             |  
---------------------------------------+------------------------------------
Changes (by john.elwell@…):

  * status:  new => closed
  * resolution:  => wontfix

Comment:

 It is believed that solutions under consideration can achieve this
 scalability. In particular, any need to enumerate the registered AORs in a
 REGISTER request can scale by making use of number ranges or ensuring that
 TCP is used for messages exceeding the maximum MTU size. Therefore this
 "desirable" can remain.

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

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 3 Mar 2010 12:58:22 +0100

The situation that 18.1.1 does not cover is where the request conforms to the rules specified in 18.1.1, and for some reason is less that the 1300 bytes, or whatever, and where the response grows beyond that. The response follows the transport mechanism of the request. We have not progressed at least one internet draft because of that problem.

So if someone wants a solution which for example puts a range of numbers in a request, and enumerate all those numbers in the response, then the requirements of 18.1.1 will not solve the issue.

regards

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Spencer Dawkins
Sent: Tuesday, March 02, 2010 6:11 PM
To: Dean Willis
Cc: [email-masked]
Subject: Re: [martini] #2: Scaling to Several Thousand Assigned Telephone Numbers

18.1.1 Sending Requests

   using an RFC 2914<./rfc2914> [43<mhtml:mid://00003169/#ref-43>] congestion controlled transport protocol, such

Spencer
----- Original Message -----
From: Dean Willis<mailto:[email-masked]>
To: Spencer Dawkins<mailto:[email-masked]>
Cc: Elwell, John<mailto:[email-masked]> ; Adam Roach<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]>
Sent: Tuesday, March 02, 2010 11:56 AM
Subject: Re: [martini] #2: Scaling to Several Thousand Assigned Telephone Numbers

I feel dirty.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 3 Mar 2010 13:13:21 -0600

On Mar 3, 2010, at 5:58 AM, DRAGE, Keith (Keith) wrote:

> The situation that 18.1.1 does not cover is where the request  
> conforms to the rules specified in 18.1.1, and for some reason is  
> less that the 1300 bytes, or whatever, and where the response grows  
> beyond that. The response follows the transport mechanism of the  
> request. We have not progressed at least one internet draft because  
> of that problem.
>
> So if someone wants a solution which for example puts a range of  
> numbers in a request, and enumerate all those numbers in the  
> response, then the requirements of 18.1.1 will not solve the issue.
>

This is unfortunately a real problem with REGISTER today, I can send a  
first REGISTER request with one contact and get back a response with  
one contact. Repeat with another REGISTER containing a new single  
contact, and the response has two contacts. Repeat a thousand more  
times, and while the requests stay the same size, the responses keep  
getting bigger -- and any 200 OK response with 1,000 contacts listed  
is going to be bigger than a single UDP packet on any common transport.

Have I mentioned lately that REGISTER is really not a great tool for  
systems with large numbers of routes? A scalable dynamic routing  
mechanism would be a much better solution for MARTINI. Doing it with  
REGISTER is just a temporary hack (arguably, a REASONABLE temporary  
hack) to get the PBX-world working until we build a real dynamic  
routing mechanism in SIP. This same lack of a dynamic routing  
mechanism is also showing up back in DISPATCH, with the proposal for  
using local private ENUM as the mechanism for informing nodes about  
routes (which I don't like much either). But at least it's a proposal  
for approaching the problem, and that's a good thing because it means  
somebody has seen another tip of the SIP "routing iceberg", and the  
more of it we can see, the better of a chance we have of navigating  
around the whole mass.

--
Dean

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 3 Mar 2010 20:22:40 +0100

Hi,

This can be solved using wildcarded AOR, assuming the numbers are assigned in a way so they "fit" into a wildcard.

Regards,

Christer

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Dean Willis [[email-masked]]
Sent: Wednesday, March 03, 2010 9:13 PM
To: DRAGE, Keith (Keith)
Cc: [email-masked]
Subject: Re: [martini] #2: Scaling to Several Thousand Assigned Telephone Numbers

This is unfortunately a real problem with REGISTER today, I can send a first REGISTER request with one contact and get back a response with one contact. Repeat with another REGISTER containing a new single contact, and the response has two contacts. Repeat a thousand more times, and while the requests stay the same size, the responses keep getting bigger -- and any 200 OK response with 1,000 contacts listed is going to be bigger than a single UDP packet on any common transport.

Have I mentioned lately that REGISTER is really not a great tool for systems with large numbers of routes? A scalable dynamic routing mechanism would be a much better solution for MARTINI. Doing it with REGISTER is just a temporary hack (arguably, a REASONABLE temporary hack) to get the PBX-world working until we build a real dynamic routing mechanism in SIP. This same lack of a dynamic routing mechanism is also showing up back in DISPATCH, with the proposal for using local private ENUM as the mechanism for informing nodes about routes (which I don't like much either). But at least it's a proposal for approaching the problem, and that's a good thing because it means somebody has seen another tip of the SIP "routing iceberg", and the more of it we can see, the better of a chance we have of navigating around the whole mass.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 3 Mar 2010 13:33:13 -0600

On Mar 3, 2010, at 1:22 PM, Christer Holmberg wrote:

>
> Hi,
>
> This can be solved using wildcarded AOR, assuming the numbers are  
> assigned in a way so they "fit" into a wildcard.

It further requires a usage guideline that says:

Don't have a bazillion REGISTER messages with different numbers and  
ranges; register no more than you can fit into a single request.  
Otherwise, the REGISTER response may be larger than the REGISTER  
request, and this leads to unpredictable results.

--
Dean

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 3 Mar 2010 20:39:24 +0100

Hi,

>request, and this leads to unpredictable results.

Yes. I think such text is much more useful than talking about exact numbers.

Maybe such text could start with: "Unless it can be ensured that TCP is used all the way between the PBX and its registrar, blah blah blah..."

Regards,

Christer

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 3 Mar 2010 14:58:54 -0600

Apparently great minds think alike :-)

I spoke with Lars and David Harrington yesterday (these will be the TSV ADs 
when MARTINI is balloted), and they said they would go for, roughly, what 
you guys said below.

Detailed report of the conversation at 
http://www.ietf.org/mail-archive/web/martini/current/msg00900.html.

Lars is expecting text along these lines to be in the protocol 
specification, saw no need for the requirements draft to address this, and 
saw no need for us to name an exact number - appropriate cautions (along the 
lines of "implementations that already violate the 'MUST use a 
congestion-controlled transport such as TCP when sending a request that is 
large enough to be IP-fragmented' in 3261 may have problems traversing NATs 
and losing fragmented IP packets when the network is congested; the solution 
is to use TCP as already required in 3261") seemed appropriate for him.

I asked John to close the issue for the requirements draft, and asked Adam 
if he needed a specific text proposal. So I think we're mostly done on this 
(important) point.

Thanks,

Spencer

> Maybe such text could start with: "Unless it can be ensured that TCP is 
> used all the way between the PBX and its registrar, blah blah blah..."
>
> Regards,
>
> Christer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 4 Mar 2010 11:59:28 +0100

That is addressing a solution, not a requirement.

The point on the requirement issue is that it was being closed on the assumption that conformance to RFC 3261 solves all the problems. It doesn't. You need extra words to say that the solution must not encompass responses that are significantly larger than the requests, unless the solution always uses a reliable transport mechanism. That margin is the 300 or so bytes mentioned in RFC 3261 18.1.1.

This is a generic requirement for all SIP mechanisms, not just MARTINI.

regards

Keith

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: Wednesday, March 03, 2010 7:23 PM
> To: Dean Willis; DRAGE, Keith (Keith)
> Cc: [email-masked]
> Subject: RE: [martini] #2: Scaling to Several Thousand 
> This can be solved using wildcarded AOR, assuming the numbers 
> are assigned in a way so they "fit" into a wildcard.
> 
> Regards,
> 
> Christer
> 
> From: [email-masked] [[email-masked]] On 
> Behalf Of Dean Willis [[email-masked]]
> conforms to the rules specified in 18.1.1, and for some 
> reason is less that the 1300 bytes, or whatever, and where 
> the response grows beyond that. The response follows the 
> transport mechanism of the request. We have not progressed at 
> least one internet draft because of that problem.
> 
> So if someone wants a solution which for example puts a range 
> of numbers in a request, and enumerate all those numbers in 
> the response, then the requirements of 18.1.1 will not solve 
> the issue.
> 
> 
> This is unfortunately a real problem with REGISTER today, I 
> can send a first REGISTER request with one contact and get 
> back a response with one contact. Repeat with another 
> REGISTER containing a new single contact, and the response 
> has two contacts. Repeat a thousand more times, and while the 
> requests stay the same size, the responses keep getting 
> bigger -- and any 200 OK response with 1,000 contacts listed 
> Have I mentioned lately that REGISTER is really not a great 
> tool for systems with large numbers of routes? A scalable 
> dynamic routing mechanism would be a much better solution for 
> MARTINI. Doing it with REGISTER is just a temporary hack 
> (arguably, a REASONABLE temporary hack) to get the PBX-world 
> working until we build a real dynamic routing mechanism in 
> SIP. This same lack of a dynamic routing mechanism is also 
> showing up back in DISPATCH, with the proposal for using 
> local private ENUM as the mechanism for informing nodes about 
> routes (which I don't like much either). But at least it's a 
> proposal for approaching the problem, and that's a good thing 
> because it means somebody has seen another tip of the SIP 
> "routing iceberg", and the more of it we can see, the better 
> of a chance we have of navigating around the whole mass.
> 
> --
> Dean
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 4 Mar 2010 12:28:04 +0100

The existing requirement on scalability is sufficient. Measures needed to ensure that the requirement can be met should be addressed as part of the solution.

John 

> [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
> Sent: 04 March 2010 10:59
> To: Christer Holmberg; Dean Willis
> Cc: [email-masked]
> The point on the requirement issue is that it was being 
> closed on the assumption that conformance to RFC 3261 solves 
> all the problems. It doesn't. You need extra words to say 
> that the solution must not encompass responses that are 
> significantly larger than the requests, unless the solution 
> always uses a reliable transport mechanism. That margin is 
> the 300 or so bytes mentioned in RFC 3261 18.1.1.
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 4 Mar 2010 08:30:27 -0600

Keith,

I'm agreeing with John here, but I am hearing what you're saying. Please 
don't think I'm blowing you off; I took your concerns seriously enough to 
chase down the TSV guys immediately when I saw your note.

Speaking as co-chair, my concern is that, as pointed out a few times in this 
thread, the concern is a generic RFC 3261 concern, and I'd prefer not to 
spend MARTINI time on this - it's much like the MEDIACTRL discussion of SIP 
INFO, that needed to move to SIP because that's where the responsibility is, 
and anything we said needed to go through SIP anyway.

I think we're in the same situation now - only the working group name has 
been changed to SIPCORE (to protect the innocent?). We're saying "gotta be 
scalable" in MARTINI, but this specific concern, that could affect 
scalability, is a generic SIPCORE concern.

Bernard - if I'm off-base here, please say so. That's why we have co-chairs.

Cullen - if I'm off-base here, please say so. That's why we have ADs.

Thanks,

Spencer

> The existing requirement on scalability is sufficient. Measures needed to 
> ensure that the requirement can be met should be addressed as part of the 
> solution.
>
> John
>