Subject: [Simple] Comments on message-sessions-02

From: [email-masked]
Date: Wed, 5 Nov 2003 17:47:36 +0200

Some comments below are more serious that others. Please respond to the ones that you think will cause some discussion is separate emails:

- General:
  - Should we use URI in the text instead of URL? The RFC that is referenced talks about URI (note if the references section, it wrongly says URL)

- Section 4: 
   - It should mention that a SEND request is also used as a keepalive mechanism (it is stays that way)-
   - It mentions that a session is ended with a SIP BYE. It should say that a session is ended using the signalling channel, for example a BYE is used in sip  
   - This section also talks about inactivity timer, and says that that hosting device invalidates the session state when timer expires. Why is it just the hosting device?

- Section 5.1:
   - Is this section normative? It have normative text like SHOULD and SHOULD not.

- Section 5.2:
   - Open issue: the attribute accept-type can be used to restrict the use of a message session. So if a session was created to send mpeg video. The accept-types attribute should only carry that mime-type. In this way, the other endpoint does not use that session to send normal messages.
   - Open issue: About avoiding timeouts for longer requests. Can we say that if there are more than 1 session to the same endpoint, then keeping any of the session alive keeps all the session alive. Eg: if you have a session for text/plain and you create a second one to send a 5gb video file, the text/plain session can be used to keepalive both sessions since they are both to the same remote end.

- Section 6:
   - Reference to RFC 3264 is probably needed here.
   - I had trouble figuring out how to send a second offer after the first offer/answer exchange, for example to add a new mime type of to add a new session. How does the new offer look like? Do we need to include the session attribute carrying the session URI again? What do we set the direction attribute to, if set at all in the second offer? Some text and examples for this issue is needed.

- Section 6.1:
   - The example is missing the accept-types attribute.

- Section 6.3:
  - the BNF provided allows accept-types to have multiple *. eg: a=accept-types: * * *
    It should be fixed to something like: 

               accept-types       = accept-types-label ":" format-list
               accept-types-label = "accept-types"
               format-list        = "*" / format-entries
               format-entries     = format-entry *( SP format-entry)
               format-entry       = (type "/" subtype)
               type               = token
               subtype            = token

   - Need to reference the ABNF RFC
   - This section should mention that the offerer should use the accept-types in the answer to send.

- Section 6.4:
   - "format entries from the m-line SHOULD NOT be repeated in this attribute". Should say accept-types instead of m-lines.

- Section 7.1:
   - msrp_url = "msrp" ":" "//" [userinfo] hostport ["/' resource]
                                                      ^^^
   - @ is missing after userinfo
   - Should include server in the BNF since the text mentions server many times, but its not to be seen in the BNF. So BNF would look like:
     msrp_url = "msrp" ":" "//" server ["/" resource]
     server   = [userinfo "@"] hostport
     resource = 1*unreserved
   - Should mandate the resource when the msrp URI is present in an SDP offer

- Section 7.1.2:
   - Why is there text describing the use of SRV if no port is present? The port is mandatory and therefore resolving should fail if no port is present. INVITE requests would then be rejected. If we want SRV, then we need to relax the MUST for port.

- Section 7.4.1:
   - The last step before section 7.4.2 talks about Exp header. That should not be there. There is no Exp header in a 200 response to a visit.

- Section 7.4.3:
   - In step 5 "The endpoint MAY attempt to send the message content again" Should we remove this text? If the message sending fails, so be it. The user can choose to send it again. This avoids the very large message being sent again (long messages have the potential to falsely timing out and the sender gets a 500 response).
   - Open issue: NO.

- Section 7.4.4:
   - an INVITE request can also terminate a message session (port 0). That should be noted along side the SIP BYE example. Otherwise implementers will think that only a BYE can terminate a message session.
   - About when to stop sending responses to SEND request. I would require that the initiator of the BYE (or any signalling request that terminates the message session) should continue to send 200 responses to SENDs until it has received a 200 for the SIP BYE. The recipient of the SIP BYE should cease responding to SENDs as soon as it sent a 200 for the SIP BYE. This allows more outstanding SENDs to complete.

- Section 7.4.5:
   - Open issue: I don't understand the open issue.
   - "Each endpoint MUST keep a similar timer..." This sounds like a third timer is present. Need to better tie this paragraph with the one before it.

- Section 7.5.1:
   - Steps for a Relay receiving a BIND request. Step 3 refers to section 7.4.5, but that section talks about inactivity timer.
   - How dies the host communicate the pre-visit timer to the visitor?
   - Steps for a Relay receiving a VISIT request. The last step should mention that the pre-visit timer is no longer valid.

- Section 7.7.2:
   - Need to mention that SEND is also used for keepalive. Or preferably, we can define an new method like KEEPALIVE as been discussed. If not, then the SHOULD contain MIME should be relaxed.

- Section 8:
  - Many examples don't have the CFLF between header and body in MSRP messages.

Regards,
Hisham

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Nov 2003 14:17:20 -0500

Hisham,

I'm glad you did such a careful review. I've commented on a few things 
below, and also split some others off into separate threads. I edited 
out all the stuff I didn't want to comment on.

	Paul

>    - It mentions that a session is ended with a SIP BYE. It should say that a session is ended using the signalling channel, for example a BYE is used in sip  

Yes, I agree. Normally I would expect people to know this sort of thing. 
But better to be safe. We may get some people new to sip who are only 
doing MSRP.

>    - Open issue: the attribute accept-type can be used to restrict the use of a message session. So if a session was created to send mpeg video. The accept-types attribute should only carry that mi…

That is a possibility, but it doesn't totally solve the problem. The 
mere fact that the accept-type is mpeg doesn't say that this is to be 
treated as a file transfer and stored rather than being rendered as it 
is received.

Also, it might prove useful to keep the 2nd session around, once 
established, in case other file transfers are requested. But they might 
turn out to be of a different file type.

>    - Open issue: About avoiding timeouts for longer requests. Can we say that if there are more than 1 session to the same endpoint, then keeping any of the session alive keeps all the session aliv…

This sounds like a *really bad* idea. This only works if the code 
processing the multiple streams is closely coordinated in some way. One 
end can't presume to know that will be the case at the other end.

We have discussed other, I think better, ways of dealing with the timeouts.

>    - I had trouble figuring out how to send a second offer after the first offer/answer exchange, for example to add a new mime type of to add a new session. How does the new offer look like? Do we…

These are really good questions, worth a separate thread.

>                format-entry       = (type "/" subtype)

I thought we were changing to having *only* a "*" on the m-line and 
doing all the rest with attributes.

>    - In step 5 "The endpoint MAY attempt to send the message content again" Should we remove this text? If the message sending fails, so be it. The user can choose to send it again. This avoids the…

Another one that deserves its own topic.

>    - an INVITE request can also terminate a message session (port 0). That should be noted along side the SIP BYE example. Otherwise implementers will think that only a BYE can terminate a message…

Yes. And UPDATE is yet another way to accomplish this.

>    - About when to stop sending responses to SEND request. I would require that the initiator of the BYE (or any signalling request that terminates the message session) should continue to send 200…

Another separate thread

>    - "Each endpoint MUST keep a similar timer..." This sounds like a third timer is present. Need to better tie this paragraph with the one before it.

I also find it confusing how many timers there are, and where. I think 
it is that each endpoint has one, while a relay has two - one on each 
side. But that isn't so clear.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Nov 2003 14:17:20 -0500

Hisham,

	Paul

Another separate thread

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Nov 2003 14:18:19 -0500

[email-masked] wrote:
>    - I had trouble figuring out how to send a second offer after the
>      first offer/answer exchange, for example to add a new mime type
 >      of to add a new session. How does the new offer look like?

Even before discussing that, it is important to be clear what an 
offer/answer that doesn't change *anything* looks like. For instance 
this might occur when attempting to do a session timer refresh, or when 
there is another media session (e.g. voice) that is being changed but 
this one isn't.

Normally, you expect that the last SDP can be exchanged without change. 
This works pretty simply for RTP and UDP. But it has presented some 
issues in comedia, and may do so here as well. The question is how to 
decide if this is a request to tear down the old session and build a new 
one, or simply to leave the old one alone.

For instance, suppose I am the visitor in the current session, and I 
have experienced a timeout - I sent something and got no response. I 
would like to try to remedy the situation. But I still need to be the 
visitor. So what can I do? I can send a reinvite. It will presumably 
look like my last one. If the other end is still present and receives 
the reinvite, I perhaps would like him to tear down the existing stream 
and offer me a chance to visit a new one.

 >      Do we need to include the session attribute carrying the session 
URI again?
 >      What do we set the direction attribute to, if set at all in the 
second offer?

I think the answer should be something like:

If the visitor initiates a new offer/answer and prefers to continue with 
the existing session, it should send the offer with a=direction:active, 
even if direction:both had been used previously. Then if the answerer 
also prefers to continue with the existing session, it should answer 
with direction:passive and include the old session URI. Receipt of an 
answer with the old session URI is a signal to the offerer to continue 
using the existing session. OTOH, if the answerer prefers to switch to a 
new media session, it should respond with a new session URI.

If the host initiates a new offer/answer and prefers to continue with 
the existing session, it should send the offer with direction:passive 
and the old session URI. Then if the answerer prefers also prefers to 
continue with the existing session, it should answer with 
direction:active, and just continue using the old session. If the 
answerer prefers to switch to a new media session it can either accept 
this as just mentioned or refuse it by setting the port to zero. Then it 
can initiate a new offer/answer cycle.

If the host initiates a new offer/answer cycle and wants to switch to a 
new media session, it may send an offer with a new session URI and with 
a direction of either passive or both. Either way is clear. All actions 
are as if starting from scratch.

If the visitor initiates a new offer/answer cycle and wants to switch to 
a new media session, and if it is capable of acting as host, it can do 
as in the prior paragraph. If it cannot, then the best it can do is to 
send an offer with a port of zero to terminate the existing session. It 
can then then do yet another offer/answer to establish a new session. 
Or, it can combine the two steps - setting the port to zero for the 
existing session but proposing a new 2nd session in the same offer.

[Is more needed to cover the two relay case???]

A reinvite to make a change like adding a new mime type, that doesn't 
require changing the connections, can be the same as above, but changing 
the attributes appropriately.

However, just as there are rules about changing codecs in reinvites, 
there probably should be rules about changing supported mime types in 
existing MSRP sessions.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Nov 2003 14:18:19 -0500

URI again?
second offer?

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Nov 2003 14:21:42 -0500

[email-masked] wrote:
> 
> - Section 7.4.3:
>    - In step 5 "The endpoint MAY attempt to send the message content again"
 >      Should we remove this text? If the message sending fails, so be it.
 >      The user can choose to send it again. This avoids the very large 
message
 >      being sent again (long messages have the potential to falsely 
timing out
 >      and the sender gets a 500 response).

I agree this should go. We may want to discuss possibility of 
establishing a replacement media session and then retrying the message 
there. In that case I think we perhaps should make it permissible for 
the retry to use the same TR-ID. It is then optional whether the 
recipient detects the duplicate or not.

This addresses the case where a relay crashes in an ungraceful way.

>    - Open issue: NO.

I guess what I am proposing is YES, but with a weak mechanism - neither 
side is *required* to enable duplicate suppression, but the mechanism is 
there if both sides choose to use it.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Nov 2003 14:21:42 -0500

message
timing out

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Nov 2003 14:30:21 -0500

[email-masked] wrote:
> 
> - Section 7.4.4:
>    - About when to stop sending responses to SEND request.
 >      I would require that the initiator of the BYE
 >      (or any signalling request that terminates the message session)
 >      should continue to send 200 responses to SENDs until it has
>      received a 200 for the SIP BYE. The recipient of the SIP BYE
 >      should cease responding to SENDs as soon as it sent a 200 for
 >      the SIP BYE. This allows more outstanding SENDs to complete.

I don't think this is good enough. Consider:

	X-----R------Y

X has sent a large message, but for some reason R has been buffering it, 
so that none has reached Y. Y thinks things are idle, and sends a BYE.

What should X do when it receives the BYE? It could wait for a response 
to its message for sending the 200 on the BYE. But if the message is 
large, the BYE might time out before the message fully arrives at Y so 
that Y may respond to it. Or X could send the the 200 for the BYE 
immediately. But then its less likely to get a response to the message.

What X needs to know is whether the messages it has sent have been 
processed by the recipient. Its especially important to know this in a 
graceful shutdown case like this.

I think the key is that in a graceful shutdown, a response must be sent 
for every message that is processed by the receiving end. Once having 
sent or received signaling initiating the shutdown of the session it may 
stop processing messages. Then, for the messages not processed, it may 
either send an error response of some sort, or else send no response.

For this to be beneficial, both ends need to drain the connection, 
processing responses, as long as they have any unacknowledged messages 
outstanding.

Message delivery failure will be minimized if both sides continue 
processing incoming messages, and sending responses to them, until an 
eof is received on the connection. This is even after the signaling is 
all completed.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Nov 2003 14:30:21 -0500

X-----R------Y

	Paul

---

From: Ben Campbell <[email-masked]>
Date: Fri, 07 Nov 2003 10:29:08 -0600

>   - Should we use URI in the text instead of URL? The RFC that is referenced talks about URI (note if the references section, it wrongly says URL)

We actually decided to change from URI to URL some time ago. RFC2396 
speaks to URLs and URNsas well as URIs, and implies that a URI is either 
a locater or a name. The MSRP scheme seems to me to more fit the URL 
definition than the URN definition. While a URL is a kind of URI, I 
don't see how it serves us to move back to the more general term.

You are correct about the title in the RFC reference being wrong.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 07 Nov 2003 10:29:08 -0600

---

From: Ben Campbell <[email-masked]>
Date: Fri, 07 Nov 2003 11:16:12 -0600

Hi--I addressed some points in separate emails. Others inline:

[...]

>    - It should mention that a SEND request is also used as a keepalive mechanism (it is stays that way)-

I think that is only coincidentally true. Any end-to-end request serves 
as a keepalive. If we were, in the future, to add some new end-to-end 
method (Not that I am proposing we do!) then I think that new method 
could _also_ serve as a keepalive. So, really, the keepalive mechanism 
is something to the effect of "periodically send end-to-end traffic" It 
just so happens that the only current way to do this is with SEND. I 
plan to re-word some of the inactivity timeout text to make this more 
clear in the next version (assuming we don't decide to change it.)

>    - It mentions that a session is ended with a SIP BYE. It should say that a session is ended using the signalling channel, for example a BYE is used in sip  

Agreed.

>    - This section also talks about inactivity timer, and says that that hosting device invalidates the session state when timer expires. Why is it just the hosting device?

Let me turn that question around. Why would any other device need to? 
When the hosting device closes the session, the endpoints will learn of 
it in short order as they get their connections closed. So will a 
visiting relay, for that matter (although I do think we have an open 
item on whether visiting relays should have to worry about the timer.)

>    - Is this section normative? It have normative text like SHOULD and SHOULD not.

Yes, section 5.1 is intended to be normative, although it contains no 
statements stronger than SHOULD. But we mean those SHOULDs just as much 
as any other SHOULDs in the document. :-)

>    - Open issue: the attribute accept-type can be used to restrict the use of a message session. So if a session was created to send mpeg video. The accept-types attribute should only carry that mi…

That is an interesting approach. But I think we may have overlap in 
types that are allowed on an IM session, and types that are allowed on a 
file transfer session. What if I want to transfer a large file of type 
text/plain?

>    - Open issue: About avoiding timeouts for longer requests. Can we say that if there are more than 1 session to the same endpoint, then keeping any of the session alive keeps all the session aliv…

I really don't like forcing a relay to know that two sessions involve 
the same pair of endpoints.

>    - Reference to RFC 3264 is probably needed here.

Agreed.

>    - I had trouble figuring out how to send a second offer after the first offer/answer exchange, for example to add a new mime type of to add a new session. How does the new offer look like? Do we…

Interesting question. It may make sense to publish a set of use cases, 
much as we have done with the SIP call flows document. I wonder if that 
belongs in the core document, or in a separate one?

>    - The example is missing the accept-types attribute.

The example in 6.1 is explicitly just an m-line, not an entire SDP document.

>                format-entry       = (type "/" subtype)

That does not seem to allow for something like "a=accept-types: 
message/cpim text/plain *", which is semantically meaningful. I can 
change the syntax to only allow one "*", but do we really care? "* * *" 
may be silly, but it can still be interpreted reasonably.

>    - Need to reference the ABNF RFC

OK

>    - This section should mention that the offerer should use the accept-types in the answer to send.

OK

>    - "format entries from the m-line SHOULD NOT be repeated in this attribute". Should say accept-types instead of m-lines.

OK

[...]

>    - Why is there text describing the use of SRV if no port is present? The port is mandatory and therefore resolving should fail if no port is present. INVITE requests would then be rejected. If w…

It is not mandatory for a URL that designates a relay that is handed to 
an endpoint out-of-band. (For example, when a user configures a client 
to use a relay.)

>    - The last step before section 7.4.2 talks about Exp header. That should not be there. There is no Exp header in a 200 response to a visit.

OK

>    - In step 5 "The endpoint MAY attempt to send the message content again" Should we remove this text? If the message sending fails, so be it. The user can choose to send it again. This avoids the…

Agreed, assuming consensus agrees on the following open issue.

>    - About when to stop sending responses to SEND request. I would require that the initiator of the BYE (or any signalling request that terminates the message session) should continue to send 200…

I need to think about this one.

>    - Open issue: I don't understand the open issue.

There is no explicit "unvisit" semantic. The visiting relay indirectly 
discovers a session has ended.

>    - "Each endpoint MUST keep a similar timer..." This sounds like a third timer is present. Need to better tie this paragraph with the one before it.

OK
>    - Steps for a Relay receiving a BIND request. Step 3 refers to section 7.4.5, but that section talks about inactivity timer.

OK

>    - How dies the host communicate the pre-visit timer to the visitor?

It doesn't. The point is not to tell the visitor that is has X time to 
connect, we assume the visitor will connect as fast as it can. The 
pre-visit timer merely tells the relay how long we want it to wait 
before giving up.

>    - Steps for a Relay receiving a VISIT request. The last step should mention that the pre-visit timer is no longer valid.

OK

>    - Need to mention that SEND is also used for keepalive. Or preferably, we can define an new method like KEEPALIVE as been discussed. If not, then the SHOULD contain MIME should be relaxed.

See previous comment.

>   - Many examples don't have the CFLF between header and body in MSRP messages.

Oops. OK.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 07 Nov 2003 11:16:12 -0600

[...]

Agreed.

Agreed.

OK

OK

OK

[...]

OK

OK

OK

OK

See previous comment.

Oops. OK.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 07 Nov 2003 15:19:17 -0600

Paul Kyzivat wrote:
[...]
> doing all the rest with attributes.

Hisham was not referring to the m-line. The BNF above refers to the 
accept-types attribute.

[...]

>>    - an INVITE request can also terminate a message session (port 0). 
>> That should be noted along side the SIP BYE example. Otherwise 
>> implementers will think that only a BYE can terminate a message session.
> 
> 

As I mentioned in a separate post, I think a throrough set of use cases 
would be useful. But do they belong in this document, or a separate one? 
Since this doc is not supposed to be normatively tied to SIP, it may 
make more sense to separate them.

[...]

---

From: Ben Campbell <[email-masked]>
Date: Fri, 07 Nov 2003 15:19:17 -0600

Paul Kyzivat wrote:
[...]

[...]

[...]

---

From: Ben Campbell <[email-masked]>
Date: Fri, 07 Nov 2003 15:22:46 -0600

> recipient detects the duplicate or not.

I don't mind mentioning that some implementations might choose to create 
a new session and attempt to resume a conversation--but I do not want to 
imply that it should or should not be done. As far as retrying the same 
TR-ID, I do not think that is useful unless we strengthen the uniqueness 
requirements for TR-ID, and recommend some period of time that an 
endpoint should remember previous ones it had seen.

> there if both sides choose to use it.

I assume the weak mechanism to which you refer is the TR-ID approach 
mentioned above. See my comments above.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 07 Nov 2003 15:22:46 -0600

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Nov 2003 18:10:25 -0500

inline...

Ben Campbell wrote:
>>  >      The user can choose to send it again. This avoids the very 
>> large message
> imply that it should or should not be done.

I agree it should be an application issue whether to do this.

 > As far as retrying the same

I'm not certain a time period is really necessary. I think this can be 
local option.

Even uniqueness across streams isn't *required*, though it would be 
helpful. Instead, we can simply introduce an error response to be used 
when a duplicate is detected and supressed. If it was supressed in error 
because the sender duplicated a TR-ID from another stream, the sender 
would then know to recover.

But I agree that some further clarification on TR-ID uniqueness could be 
helpful.

>> I guess what I am proposing is YES, but with a weak mechanism - 
>> neither side is *required* to enable duplicate suppression, but the 
>> mechanism is there if both sides choose to use it.
> 

yes.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Nov 2003 18:10:25 -0500

inline...

yes.

	Paul

---

From: Ben Campbell <[email-masked]>
Date: Mon, 10 Nov 2003 11:08:51 -0600

Paul Kyzivat wrote:

[...]

> But I agree that some further clarification on TR-ID uniqueness could be 

If TR-ID is not required to be unique across sessions, and you allow 
clients to attempt to find duplicate messages using TR-ID across 
sessions, then you introduce the possibility of false detection caused 
by TR-ID collisions. This seems bad to me.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 10 Nov 2003 11:08:51 -0600

Paul Kyzivat wrote:

[...]

---

From: Aki Niemi <[email-masked]>
Date: Mon, 10 Nov 2003 23:30:31 +0200

Hi,

At this point I'm really confused about the true meaning for TR-ID.

The current draft reads to me that the TR-ID should be unique within a 
session, but there still isn't any duplicate suppression on the 
recipient side. If this is the case, I don't even see why TR-ID needs to 
be unique within a session. It would seem enough for the sender not to 
have TR-ID collisions occur within the set of *pending* requests. in 
other words, the TR-ID is opaque to the recipient - whatever the request 
had is used in the response.

Having said that, I think TR-ID is not working to its full potential, 
and thus I have a new proposal.

Let's make TR-ID a simple counter. Each session starts from zero, and 
each new message increments this counter. We can come up with a 
reasonable resolution for this counter; x seems as good a value as any. 
When the counter hits x, it is reset to zero.

The good thing is that we get duplicate detection without the recipient 
having to remember all used TR-IDs within a session, but it suffices to 
maintain this unidirectional counter on each end.

Whatever the resolution will be, it seems a reasonable limitation to say 
that a sender can only have x pending requests at a time.

Cheers,
Aki

ext Ben Campbell wrote:

>> when a duplicate is detected and supressed. If it was supressed in 
>> error because the sender duplicated a TR-ID from another stream, the 
>> sender would then know to recover.
>>
>> But I agree that some further clarification on TR-ID uniqueness could 
>> be helpful.
>>
>

---

From: Aki Niemi <[email-masked]>
Date: Mon, 10 Nov 2003 23:30:31 +0200

Hi,

Cheers,
Aki

---

From: Ben Campbell <[email-masked]>
Date: Mon, 10 Nov 2003 15:55:26 -0600

> had is used in the response.

The real requirement for the current usage is exactly as you say, that 
is, no collisions within the set of pending requests. Making them unique 
inside a session simply seemed the easiest way to enforce this.

> that a sender can only have x pending requests at a time.

This is interesting. We originally avoided this approach due to 
potential problems with shared connections, etc. These problems may all 
be gone with the current version. One potential problem comes to mind 
is, if TR-ID 2 times out _and_ was never presented to the recipient, 
TR-ID 3 is delivered, then TR-ID 2 is resubmitted, it may falsely be 
treated as a duplicate. Now, I am not sure this can really happen 
assuming TCP connections all the way. If the receiving peer is 
overloaded, but recovers well enough to process TR-ID 3, then TR-ID 2 
will most likely get processed first anyway, wouldn't it?

  Does anyone recall a problem with requiring ordered, contiguous TR-ID 
values, and allowing the receiving peer to notice discrepancies, that is 
still relevant?

> 
> Cheers,
> Aki
> 
> ext Ben Campbell wrote:
> 
>> Paul Kyzivat wrote:
>>
>> [...]
>>
>>>
>>> I'm not certain a time period is really necessary. I think this can 
>>> be local option.
>>>
>>> helpful. Instead, we can simply introduce an error response to be 
>>> used when a duplicate is detected and supressed. If it was supressed 
>>> in error because the sender duplicated a TR-ID from another stream, 
>>> the sender would then know to recover.
>>>

---

From: Ben Campbell <[email-masked]>
Date: Mon, 10 Nov 2003 15:55:26 -0600

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Nov 2003 17:26:58 -0500

Its true that within a given session it should be sufficient to 
distinguish between the currently pending messages. So TR-IDs for 
acknowledged messages could be recycled.

OTOH, without some tweaks that makes the problem of failing over to 
another session harder.

This could perhaps be handled by making a two-part TR-ID: 
<generation>.<id>. So when a session is established for the first time, 
ids are of the form 1.1, 1.2, ... Then, if it is necessary to fail over 
to a new session, then ids for new messages are 2.1, 2.2, ..., but 
retransmissions of old ones would still carry their original TR-ID.

A recipient that supports duplicate suppression would need to remember 
the ids of messages processed until certain the response had been 
received by the sender. This could be handled a number of different ways:
- reuse of a TR-ID in the *same* session isn't a retransmission. It
   redefines what message it applies to.
- if a request is sent in the other direction, any responses sent
   prior to it can be inferred to have been received, so the messages
   corresponding to those responses will no longer be eligible for
   retransmission.
- the timeout interval for messages puts an upper bound on how
   long one needs to be prepared to deal with retransmissions of
   a message.

	Paul

Ben Campbell wrote:
>> recipient side. If this is the case, I don't even see why TR-ID needs 
>> to be unique within a session. It would seem enough for the sender not 
>> to have TR-ID collisions occur within the set of *pending* requests. 
>> in other words, the TR-ID is opaque to the recipient - whatever the 
>> request had is used in the response.
> 
> 
>> reasonable resolution for this counter; x seems as good a value as 
>> any. When the counter hits x, it is reset to zero.
>> The good thing is that we get duplicate detection without the 
>> recipient having to remember all used TR-IDs within a session, but it 
>> suffices to maintain this unidirectional counter on each end.
>>
>> Whatever the resolution will be, it seems a reasonable limitation to 
>> say that a sender can only have x pending requests at a time.
> 
> 
>>>> But I agree that some further clarification on TR-ID uniqueness 
>>>> could be helpful.
>>>>
>>>
>>> sessions, then you introduce the possibility of false detection 
>>> caused by TR-ID collisions. This seems bad to me.
>>>
>>>
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Nov 2003 17:26:58 -0500

Paul