Subject: RE: [Simple] Re: Draft-campbell-simple-im-session-01: Head of Li ne Blocking

From: Adam Roach <[email-masked]>
Date: Mon, 21 Apr 2003 15:46:48 -0500

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> 
> If  two corporation each have a relay, and the relays reuse a single
> connection between them, a user transferring a 5G file will 
> block all IM
> between the two corporations. This seems unacceptable. We 
> either need a way
> for relay to fragment the message or a way to negotiate the 
> maximum block
> size. 

While SCTP streams would certainly provide a long-term
solution, I don't think it's reasonable to delay
deployment of message sessions until SCTP is widely
used.

In the short-term, my guess is that the only workable
solutions are:

 1) Don't re-use connections between users. That is,
    if you sent a 5 GB file, you block only your own
    traffic, not other users'.

 2) Limit message sizes. Fail anything larger than an
    administratively-determined limit.

 3) Chunk the messages in MIME. The use of message/partial
    (or, if the semantics are judged to be too different,
    "message/msrp-partial") would allow sending UAs to split
    messages into reasonable sizes (either negotiated or
    protocol-mandated).

 4) Chunk the messages in MSRP. This could work similar to the
    BDAT SMTP command described in RFC 3030, but with an added
    "Message-ID" to correlate parts. e.g.:

        MSRP 10000 PART
        T-URI: msrp:[email-masked]
        TR-ID: 123
        Message-ID: 4
        Content-Type: "image/png"

        [first part of body]

        MSRP 10000 PART
        T-URI: msrp:[email-masked]
        TR-ID: 124
        Message-ID: 4
        Content-Type: "image/png"

        [second part of body]

        MSRP 918 PARTEND
        T-URI: msrp:[email-masked]
        TR-ID: 125
        Message-ID: 4
        Content-Type: "image/png"

        [third part of body]

It should be noted that this method also provides a
solution to the problem that Cullen raised in the framing
thread: if the sender does not know how large the message
content will be when it starts sending, it can just bundle
up generated output in small chunks and send them as parts.

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

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 21 Apr 2003 22:43:49 -0700

This is tightly coupled with my framing question. Let me comment on some of
your solution inline.

I like the solutions you have where I can allocate a buffer, start filling
it  and when it gets full, back patch the size into some blank space I left
of the size then send the buffer. However, keep in mind what it looks like
when I am doing S/MIME at the same time.

I know some people must think we are way off in the weeds worrying about
this sort of implementation details but I think it vaguely is worth
something in this case.

> deployment of message sessions until SCTP is widely
Agreed - I am not saying we should require SCTP - that does not seem like a
practical solution yet.

>   traffic, not other users'.
Causes real problems in that we can't get any fan in to reduce the number of
TCP connections. Hope we can do better than this.

>   administratively-determined limit.
Reasonable - though now would be nice if the relays could tell this MTU to
clients. Also be nice for the client to be able to indicate that the current
fragment was the last one in the message so we do not need a high level
framing protocol. 

>   messages into reasonable sizes (either negotiated or
Since we are doing MIME anyways ideas on this path are appealing. Could you
do it a way where the Relay could actually split something up into smaller
size chunks that the client sent?

>   "Message-ID" to correlate parts. e.g.:
This might be workable too - again - could the Relay re-chunk something into
smaller chunks.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 22 Apr 2003 10:06:01 -0400

Adan,

In your alternative (4), are messages always partitioned at the source, 
or may relays along the path partition messages?

If only the source can do the partitioning, you have a solution to the 
framing problem for streamed messages, but you don't necessarily have a 
solution to head of line blocking.

To solve head of line blocking, either a sufficiently small maximum 
fragment size must be chosen, or else relays need the ability to 
partition on their own.

 From a practical point of view, either approach would probably be 
sufficient. But permitting the relays to partition seems more flexible.

I like this approach because it kills two birds with one stone. Of 
course what this does is reimplement part of SCTP, but I agree that it 
would be unreasonable to require SCTP at this time.

	Paul