Subject: RE: [Simple] MSRP Boundary header

From: "Vijay Hampapur Hampapur Parthasarathy" <[email-masked]>
Date: Tue, 29 Jun 2004 13:26:40 -0700

But the Stack that is sending this stream out needs to packetise it at
some point, at that point in time we do know the exact length of the
amount we are sending in this one packet and that can be included as a
header. And if you are talking about relays that need to rechunk
messages for slow b/w links, then they already know how much of the
message has been received and what size of chunk is acceptable on this
segment in order to split it up.

Maybe I don't fully understand the specific streamin application you
have in mind where this kind of unknown length upfront would be
required.

Thanks
Vijay

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Tuesday, June 29, 2004 1:19 PM
To: Vijay Kishen Hampapur Parthasarathy
Cc: Aditya Bhasin; [email-masked]
Subject: Re: [Simple] MSRP Boundary header

That works if you abort message content between chunks. We are talking
about either aborting or splitting a chunk in mid-stream. And the 06
draft already has something similar to your idea of an ENDOFMESSAGE flag
in the continuation flag.

The problem if, if you put a content-length at the front of a message,
you obviously have to know how long that message is in advance. If I
need to interrupt a chunk at some arbitrary point in its transmission, I
have violated that knowledge.

Vijay Hampapur Hampapur Parthasarathy wrote:

> Why cannot this be handled with a content length header that specifies

> the length of this chunk. And another header, say an ENDOFMESSAGE 
> header bool, that specifies if the message is completely done or more 
> pieces are present. This way the logic to parse would not need to look

> thro the entire message before sending (in order to ensure the 
> boundary characters arent present) and to parse when reading to see 
> where the current chunk (/message) ends
> 
> Vijay
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ben Campbell
> Sent: Monday, June 28, 2004 3:47 PM
> To: Aditya Bhasin
> Cc: [email-masked]
> Subject: Re: [Simple] MSRP Boundary header
> 
> The ability to handle large content has been a generally accepted 
> requirement. The entire chunking mechanism is there due to this 
> requirement.
> 
> I do not understand what you mean by "being close to the application".

> There a a number of ways an application could talk to the MSRP layer. 
> For an absurdly trivial example, you could simply pipe output from an 
> app, and have MSRP recognize the end-of-file.
> 
> Aditya Bhasin wrote:
> 
> 
>>What applications are being targeted for this to be an issue?
>>
>>The size of the content will have to be extremely large and the 
>>application pretty close to a streaming application to be able to 
>>insert an ending boundary delimiter.
>>
>>Sorry late to the discussions and only trying to understand what is 
>>driving this requirement.
>>
>>thx
>>-----Original Message-----
>>From: Ben Campbell [mailto:[email-masked]]
>>Sent: Monday, June 28, 2004 3:30 PM
>>To: Aditya Bhasin
>>Cc: [email-masked]
>>Subject: Re: [Simple] MSRP Boundary header
>>
>>If you use message-length for framing purposes, then once you have 
>>sent the message-length value, you have to send that many bytes. If 
>>you don't, the peer cannot tell when the current message ends and the 
>>next one starts. Once the peer loses track of framing in this way, 
>>framing is lost for the entire connection.
>>
>>We could probably fix this with some sort of sync protocol, but that 
>>would be more complex than just going to a delimiter approach to 
>>framing, which is exactly what the boundary is.
>>
>>
>>
>>Aditya Bhasin wrote:
>>
>>
>>
>>>Ben,
>>>
>>>Could you explain this a little more.
>>>
>>>Thx
>>>
>>>aditya
>>>
>>>-----Original Message-----
>>>From: [email-masked] [mailto:[email-masked]] On 
>>>Behalf
>>
>>Of
>>
>>
>>>Ben Campbell
>>>Sent: Monday, June 28, 2004 2:04 PM
>>>To: Murty Dasari
>>>Cc: [email-masked]
>>>Subject: Re: [Simple] MSRP Boundary header
>>>
>>>The reason is, we added a requirement to be able abort a message 
>>>without destroying framing for the TCP connection. The boundary 
>>>approach has that property, content-length does not.
>>>
>>>Murty Dasari wrote:
>>>
>>>
>>>
>>>
>>>>Hello,
>>>>
>>>>
>>>>
>>>>I've a question about MSRP (based on
>>>>draft-ietf-simple-message-sessions-06.txt) "Closing" field.
>>>>
>>>>
>>>>
>>>>What is the need for a "Closing" field?
>>>>
>>>>
>>>>
>>>>Can't we use "Content-Length" similar to HTTP for determining the 
>>>>message body length? If this is there for "Continuation-Flag" then 
>>>>probably we can have another header that indicates continuation
> 
> status.
> 
>>>>Though it might not be lot of work to determine the "closing" tag, 
>>>>it
> 
> 
>>>>might be easy for the relays and clients to retrieve the message 
>>>>body
> 
> 
>>>>based on content-length header; further, we don't have to add 
>>>>restrictions on presence of "boundary" in the message body in this
> 
> case.
> 
>>>>
>>>>
>>>>This question might have brought-up/answered earlier, but I couldn't

>>>>find out from the archives. Appreciate any comments.
>>>>
>>>>
>>>>
>>>>Thanks for your time.
>>>>
>>>>- Murty
>>>>
>>>>
>>>>
>>>>
>>>>--------------------------------------------------------------------
>>>>-
>>>>---
>>>>
>>>>_______________________________________________
>>>>Simple mailing list
>>>>[email-masked]
>>>>https://www1.ietf.org/mailman/listinfo/simple
>>>
>>>
>>>_______________________________________________
>>>Simple mailing list
>>>[email-masked]
>>>https://www1.ietf.org/mailman/listinfo/simple
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple

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

---

From: "Sean Olson" <[email-masked]>
Date: Tue, 29 Jun 2004 19:48:18 -0700

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

For (1), the content length is usually small and certainly known in advance.
There isn't much point in chunking up the content and it's a bit overkill to
have to parse for a content
boundary

For (2), chunking makes sense and in some streaming applications, it make be
impossible to know the TOTAL
content length in advance

Both can easily be accommodated with the same protocol much as is done with
HTTP. 
If the Content-Length is present, it represent the total message size and
there is no need for chunking
If the Content-Length is not present, use chunking/boundary delimiter to
stream the content

The choice of which to use will typically be made based on content size and
is a simple implementation decision.
For example, for messages larger than 2K, it probably makes sense to chunk
up the content. Otherwise, why not use
a simpler approach.

Of course, you can combine the two choices into a hybrid approach. Use a
byte-range header plus a end-of-message header. For the simple case (1), you
set the byte-range to represent the entire content length and set the
end-of-message header to true. For the more complex case (2), you chunk up
the content and use the byte-range to indicate the size of the chunk, the
end-of-message header to indicate continuations, and (if desired)a Boundary
header to allow mid-chunk termination of the message. Of course, if you
choose the chunk size appropriately, it should be pretty rare that you would
want to terminate the message mid-chunk

Bottom line, I don't see why applications that fall into category 1 should
pay the overhead of applications that fall into category 2 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Vijay Hampapur Hampapur Parthasarathy
Sent: Tuesday, June 29, 2004 1:27 PM
To: Ben Campbell
Cc: [email-masked]
Subject: RE: [Simple] MSRP Boundary header

But the Stack that is sending this stream out needs to packetise it at some
point, at that point in time we do know the exact length of the amount we
are sending in this one packet and that can be included as a header. And if
you are talking about relays that need to rechunk messages for slow b/w
links, then they already know how much of the message has been received and
what size of chunk is acceptable on this segment in order to split it up.

Maybe I don't fully understand the specific streamin application you have in
mind where this kind of unknown length upfront would be required.

Thanks
Vijay

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]]
Sent: Tuesday, June 29, 2004 1:19 PM
To: Vijay Kishen Hampapur Parthasarathy
Cc: Aditya Bhasin; [email-masked]
Subject: Re: [Simple] MSRP Boundary header

That works if you abort message content between chunks. We are talking about
either aborting or splitting a chunk in mid-stream. And the 06 draft already
has something similar to your idea of an ENDOFMESSAGE flag in the
continuation flag.

The problem if, if you put a content-length at the front of a message, you
obviously have to know how long that message is in advance. If I need to
interrupt a chunk at some arbitrary point in its transmission, I have
violated that knowledge.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 29 Jun 2004 20:21:09 -0700

>2) Larger, more complex, richer messages as forseen in 3G and other

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?

			regards,
				Ted Hardie

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 29 Jun 2004 20:07:51 -0700

If the largest chunk you ever sent was 2k, then you can probably get away
with this knowing before you send the chunk if you can send the whole thing
or not. This 2k number is debatable but it's close enough for discussions
sake. However, this results in a less efficient use of the bandwidth because
of protocol overhead if you want to sent 100k. So the idea is to allow a
100k block to be sent and if it needs to be interrupted, interrupt it. If
the 2k number is smaller than 2k (as some people have suggested) this
becomes even more important.

You do not need to scan the whole message ahead of time to see if it
contains the boundary. You can incrementally scan and if you find the
boundary, interrupt just before it occurs and start sending with a new
boundary. 

This also allows you to build streaming relays that just send as they
receive and interrupt only when needed. You can also build store and forward
relays if you want.

There is quite a bit of discussion on this "framing" issues in the archives.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 30 Jun 2004 09:17:08 -0400

> 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.

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.

	Paul

---

From: Ben Campbell <[email-masked]>
Date: Wed, 30 Jun 2004 08:20:23 -0500

> 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.

> 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.