Subject: [Simple] RE: MSRP: 64k ought to be enough for anyone ...

From: Adam Roach <[email-masked]>
Date: Thu, 24 Apr 2003 15:03:28 -0500

"64k ought to be enough for anyone..." is typically used
to point out that technology tends to outpace even the
wildest expectations of people who are considered
visionary in their field. Your usage is unintentionally
ironic, as this would generally argue that the objections
you raise will evaporate more quickly than any of us would
reasonably expect.

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> 
> The 64K limit is pretty brutal for a wireless connection - 
> but lets just say
> we go with some limit to illustrate another problem. Assume a 
> client has one
> connection to the relay that is connected to 10 other relays for 10
> different sessions the user is in. It starts receiving this 
> 64k chunk and
> decides that it would like to kill that session but not the 
> other 9 it is
> involved with. The client send up a message to the relay to close that
> stream but now it has to keep listening to at least the end 
> of that chunk so
> that it can keep the stream synchronized.

For wireless data connections, you realistically get on
the order of 30-60 kbps with 1xRTT and GPRS. So, this 64k
message will take maybe 10 to 20 seconds to clear, if you're
not compressing it. 1xEV and EDGE will only improve this over
the next couple of years.

Dial-up connections are in the range of 20-50 kbps, which
gives roughly the same delay. (Admittedly, I'm ignoring CDPD,
2400 bps dial-up connections, and hand-tapped Morse code.)

From a practical perspective, I'd expect any wireless
implementation to use either SigComp or TLS with deflate
compression. With SigComp, if I anticipate this situation
when I design my bytecodes, I could clear the remainder of
the message with four bytes (two bytes as an escape, two
bytes to say "output this many characters of trash"). If
I'm just using plain deflate (e.g. with TLS), then I can
pump out 258 characters of output with only 13 bits on the
wire, which means that I can clear any block up to and
including 64k in size with 415 bytes (or fewer) over the air.

> The wide variation of speed between a wireless link and a 
> 1Gpbs LAN make me
> suspect that we can't use a static chunk size. Either taking 
> the min of the
> two relays said they would support or allowing the relays to 
> rechunk the
> message seem like reasonable solutions.

We thought of this. The problem is that there is no
non-onerous way to determine the path max size
before sending the first message. Keep in mind that
the relays don't even start to talk to each other
until the first "SEND" message is encountered.

Further, adding a "max size" negotiation procedure
at this point would take at least as much specification
as defining a chunking mechanism itself. If we're going
to specify additional procedures, I'd prefer that they
solve the problem, instead of investing the same amount
of work just to leave room solve the problem later.

/a
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 24 Apr 2003 22:28:53 -0700

(Even if you are skipping most of these email - read the proposal at the
bottom of this one)

Ok, one more possibly nit picky problem. Imagine two clients (C1 and C2)
that are using SIP and MSRP with two relays (R1 and R2).

C1 <--> R1 <---> R2 <---> C2

They set up a MSRP session and both sides do the bind and visit and
everything looks good but some firewall between R1 and R2 is blocking all
traffic. I think we need to know at session set up that this path does not
work - finding out *after* the first message is sent is too late. Let me try
to explain why ....

Imagine that the accounting department at some company is inside a firewall
that does not allow incoming TCP connections but does allow outgoing. Now
imagine the accounting firewall connects to the LAN which connects to the
internet via a similar firewall. If a user in accounting wants to IM to a
user in engineering then a relay needs to be outside of the accounting
firewall. The relay should likely not be outside the corporate firewall
simply to keep the traffic inside the corporate firewall. However, if the
same user in accounting wants to IM to someone in another company, they need
to use a relay outside of the corporate firewall. ICE provides a reasonable
solution to this but we need to be able to tell the connection failed before
sending real messages.

From a purely human factors point of view consider this - I click on my
buddy and the IM system says I connected to my buddy and opens a window, I
type in a message, then the IM system tells me it lied about being able to
connect. Sounds pretty lame to me.

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

So let me suggest a proposal along the following lines...

C2 sends a BIND to R2 gets a URL, a secret, and a max block size and sends
these over SIP/SDP to C1. C1 does a VISIT to R1 which does a VISIT to R2. R1
lets C1 know if the VISIT worked or not and also passes back a max block
size. 

The BIND can be digest challenged by R2 using a credential C2 has with R2.
The VISIT can be challenged by R1 using a credential C1 has about R1. The
VISIT can also be challenged by R2 and the password is the secret that C2
sent to C1. Other messages are not challenged but are not allowed unless a
BIND or VISIT has succeeded for that URI.

Here C1 has found the max size that R1, R2, and C2 are willing to accept and
does not send messages larger than that.

This whole process set up a stream from C1 to C2. A mirror process is done
to set up C2 to C1 - the fact that they can reuse the same TCP connections
is just an convenient artifact of the transport layer.

The protocol is only defined for the two relay case but a client is welcome
to host it's own relay in the same process if knows that it can accept
incoming connection from the public internet.

If you want, I can write text on this. I think this is a reasonable solution
to getting a early connection error - I also think it is a better security
solution. I don¹t really know if it is a reasonable solution to the HOL
stuff or even if HOL is a problem.

Cullen

---

From: Ben Campbell <[email-masked]>
Date: 25 Apr 2003 09:24:41 -0500

I recognize the problem--in fact, the original design team discussed
this particular issue. We decided to punt on it for several reasons.

1) As we saw it, the primary purpose of relays in the _first_ place was
to get around restrictive firewalls. Putting a relay behind such a
restrictive firewall rather misses the whole point. Honestly, the this
particular motivation was the reason we decided to explicitly cover
relays _at_all.

2) We have already put more stringent requirements for firewall
traversal on MSRP with SIP than we do with RTP and SIP. Personally, I
think we need to draw a line and not take that much further.

So, my personal preference is not to pursue this requirement. Of course,
if consensus indicates otherwise, then I will yield to it.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 25 Apr 2003 08:28:50 -0700

Mostly agree - inline

> particular motivation was the reason we decided to explicitly cover

Agree - actually I think the point of the whole session mode protocol at all
is to support relays to solve the firewall/NAT problem. Otherwise we could
just use page mode over a TCP connection directly from the UAS to the UAC.

> think we need to draw a line and not take that much further.

I agree that drawing the line of IM will work where RTP works sounds about
right. However I strongly disagree that voice will not work in the scenario
I am describing.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 25 Apr 2003 09:09:21 -0700

Seems like there should be a default well known port number so that FW
administrators can click the "Allow MSRP" toggle box on the FW.

Once again, given that the FW are set up this way, it brings up the question
of how well it is going to scale. Does anyone know how many separate
connection a web server can support all on one IP address and on port 80?

---

From: Sean Olson <[email-masked]>
Date: Fri, 25 Apr 2003 10:29:44 -0700 (PDT)

> administrators can click the "Allow MSRP" toggle box

Sounds reasonable. How about 5060? :-)

> connection a web server can support all on one IP

Why does this have to be single entity? And if it
is a single entity, why does that single entity have
to be the application termination point?

__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 25 Apr 2003 18:14:13 -0500

> Once again, given that the FW are set up this way, it brings 
> up the question of how well it is going to scale. Does anyone 
> know how many separate connection a web server can support 
> all on one IP address and on port 80?

Ooh, we went all through this on the SIP list last year arguing about TCP
for SIP proxies and what this implied about fan-in.

The answer is TCP stack dependent, and consequently OS dependent as most OS
use a filehandle or descriptor for each socket (so it doesn't matter how
many ports or how many IP addreses are used). In short, it is uncommon to
exceed 64k handles or descriptors in a modern kernel. Maybe some of the
64-bit variants can do more -- I just don't know. Once upon a time, this was
a kernel-config parameter, and on some systems I remember it being as low as
64 by default, but that was before you, Cullen, encountered puberty, and we
still had to walk uphill both ways in the snow to compile a kernel and then
wedge it into 256k of memory so it could be shared by thirty or forty users
(and I really don't know why the people with only 16MB in their mobiles
compain about scare resources -- heck, I started with 256 BYTES, soldered on
8 bits at a time).

Another set of issues around TCP is "how many half-open connections can be
supported." This was a big deal when I was building web server farms on
early Solaris boxes ~ten years ago, as the kernel could only handle 16
half-open connections (it could be patched to 256), and HTTP 1.0 produced a
LOT of connection churn. I think kernels are better now, and HTTP 1.1 has
helped a lot too. I suspect with the relatively high persistence of MSRP
that this won't be the limiting factor.

So, for all practical purposes, the best answer I can give you is "less than
64k".

--
Dean