Subject: RE: [Simple] MSRP Boundary header

From: "Chris Boulton" <[email-masked]>
Date: Thu, 1 Jul 2004 08:27:33 +0100

I agree with Ben - why do something twice.  This only increases
complexity and potential to provide conflicting + syntactically
incorrect semantics.

Chris.

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: 30 June 2004 19:35
To: Vijay Kishen Hampapur Parthasarathy
Cc: Ted Hardie; Paul Kyzivat; [email-masked]; [email-masked]
Subject: Re: [Simple] MSRP Boundary header

Because having two ways to do the same thing adds complexity to both the

implementation and the specification.

Vijay Kishen Hampapur Parthasarathy wrote:

> Can you comment on the initial question on why not allow both methods
> for message framing.  
> 
> Vijay
> 
> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]] 
> Sent: Wednesday, June 30, 2004 6:20 AM
> To: Paul Kyzivat
> Cc: Ted Hardie; [email-masked]; Vijay Kishen Hampapur
> Parthasarathy; [email-masked]
> Subject: Re: [Simple] MSRP Boundary header
> 
> 
> 
> Paul Kyzivat wrote:
> 
> 
>>
>>Ted Hardie wrote:
>>
>>
>>>At 7:48 PM -0700 6/29/04, Sean Olson wrote:
>>>
>>>
>>>>Why not allow both methods?
>>>>It seems clear that there are probably two common use cases:
>>>>
>>>>1) Simple, brief messages as in today's IM conversations
>>>>2) Larger, more complex, richer messages as forseen in 3G and other 
>>>>environments
>>>
>>>
>>>
>>>Sorry to ask such a potentially silly question, but aren't the 
>>>messages in case one to be handled by SIP/SIMPLE, rather than MSRP?
>>
>>
>>No. Maybe if you have a one-shot message it should be. But if you are 
>>having a conversation composed of simple brief messages then I believe
> 
> 
>>the expectation is that you would be using MSRP.
>>
> 
> 
> Or at one composed of a series of short, interactive messages. (Which
is
> probably what Paul meant to say.
> 
> 
>>At least that is my expectation. One subject that has yet to be dealt 
>>with is the relationship (and possibly migration) between page mode 
>>and session mode. The fact that you ask the question you did is an 
>>indication that this isn't a solved problem.
>>
> 
> 
> This is true. We have had discussions indicating that we need to say
> something about when to use each, and how to transition between them.
> 
> I personally think that sort of thing belong in the SIMPLE
architecture
> draft effort, which we have not been putting much effort into of late.
> 
> 
>>    Paul

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

This message has been scanned for viruses by MailControl - www.mailcontrol.com

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

---

From: Sean Olson <[email-masked]>
Date: Thu, 1 Jul 2004 10:28:36 -0700 (PDT)

Simple. You have two different usage scenarios. One
way is appropriate for one usage and the other way is
appropriate for the other usage. This is no different
than HTTP which supports both mechanisms (today).

The "complexity" of supporting both is very minimal
and in fact the hybrid approach I suggested makes this
trivial and transparent to the implementor.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 01 Jul 2004 11:04:55 -0700

This whole discussion is premised on the idea that framing by finding a
length header is somehow much more efficient, faster, etc than the boundary
framing. I like to poke at that a little. This efficiency is probably only
relevant on relays or things dealing with lots of messages and these run on
machines where the CPU has a cache.

The experiments I have been playing with show that given the boundary
recommendations that we are making that allow you to check for a "----"
 4 bytes at a time allow you look for boundary at the same rate that the
memory can be copied. Basically the bandwidth from main memory to cache is
the bottleneck and the extra check if the 4 byte value is "----" takes no
extra time - the CPU is mostly idle waiting for the cache to fill. If you
send a message which consisted of a special constructed message that looked
very similar to the boundary, this might slow down but this is an artificial
corner case I can't get worked up about.

I know of no reason for MSRP to prefer the length to the boundary scheme. If
someone has one, let's get that on the table and establish if there is a
real need to do both. The downside about both is interoperability issues
when people only implement one.

I point out that I can find boundaries at the same rate I can copy memory
and this is way way way beyond the total network bandwidth that can flow in
or out of my machine. I'm missing what the argument for doing both is.

Cullen

---

From: "Murty Dasari" <[email-masked]>
Date: Thu, 1 Jul 2004 11:59:35 -0700

Hi Cullen,

As you pointed out the content-length is useful for relays and processes
that deal with lots of messages.

One use case is multiparty MSRP server based on SIP based conference
(draft-ietf-sipping-conferencing-framework-01) ideally the multiparty MSRP
server doesn't have to really parse the data to determine the boundary of
the message. I agree that checking for 4 byte value of "----" is much faster
than normal string comparison but it wouldn't be as fast as reading the
content-length bytes from the stream and passing it over to other MSRP
endpoints.

Thanks
- Murty

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Cullen Jennings
Sent: Thursday, July 01, 2004 11:05 AM
To: Chris Boulton; Ben Campbell; Vijay Kishen Hampapur Parthasarathy
Cc: Ted Hardie; Paul H Kyzivat; [email-masked]; [email-masked]
Subject: Re: [Simple] MSRP Boundary header

Cullen

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 01 Jul 2004 12:57:56 -0700

No - this is exactly the opposite of what I what I said.

> that deal with lots of messages.

No I said it was NOT useful for this because it was NOT faster

> content-length bytes from the stream and passing it over to other MSRP

No I did not say it was faster than string compare. I said it was EXACTLY as
fast as coping the memory using the content length approach. You need to
copy the memory to send it or use even if you are using the length approach.

I also said that even if this was slower, this was not a relevant limiting
factor of any system I have considered because it was so much higher than
the network bandwidth and the other things that devices need to do.

I would be happy to see any data suggesting otherwise (for a message that
was not already in the cache)