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

From: [email-masked]
Date: Tue, 11 Nov 2003 01:26:09 +0200

Again I ask: why is there a need for retransmission? As I said earlier, if a message fails (timeout or 5xx), the end user gets presented with this error and it is up to him/her to send it again.

If it was a long message and a timeout has occurred, then only the user can decide to send it again (again I'm pointing out that long messages can wrongly time out)

/Hisham

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, November 11, 2003 12:27 AM
> To: Ben Campbell
> Cc: Niemi Aki (NMP/Helsinki); Khartabil Hisham (NMP-MSW/Helsinki);
> [email-masked]
> Subject: Re: [Simple] Comments on message-sessions-02 - message retry
> 
> 
> 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:
> > Aki Niemi wrote:
> > 
> >> 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 5
> >> request 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.
> > 
> >>
> >> 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.
> > 
> > 
> > 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.
> >>>>
> >>>> 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.
> >>>>
> >>>
> >>> 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.
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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: Ben Campbell <[email-masked]>
Date: Mon, 10 Nov 2003 19:53:44 -0600

In spite of the fact I keep letting myself get trapped into talking 
about retransmitting, I think I agree. If one attempt fails, it seems 
highly unlikely another attempt will suddenly succeed.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 10 Nov 2003 19:53:44 -0600

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Nov 2003 10:40:34 -0500

I agree that retransmission over the same connection is useless and 
shouldn't be attempted. The issue is retransmission of messages pending 
on the old session when switching to a replacement session. That 
situation can arise if for instance a relay crashes. In that case the 
endpoint may well recover by establishing a new session and 
retransmitting any messages not confirmed on the old one.

Of course Hisham is right that it is possible to leave the decision to 
retransmit to the user of the application. This has a couple of problems:
- the end user presumably doesn't have access to tools for suppressing 
duplicates. So in cases where the old message had been process but the 
response not delivered this will result in a duplicate message. This can 
be mitigated somewhat by clarifying conversation between the users at 
the two ends.

- automata at one end or the other will be further limited. They are 
likely to be less tolerant of problems and less able to mitigate the 
problems via informal communication.

	Paul

	Paul

Ben Campbell wrote:
>> Again I ask: why is there a need for retransmission? As I said 
>> earlier, if a message fails (timeout or 5xx), the end user gets 
>> presented with this error and it is up to him/her to send it again.
>>
>> If it was a long message and a timeout has occurred, then only the 
>> user can decide to send it again (again I'm pointing out that long 
>> messages can wrongly time out)
>>
>> /Hisham
>>
>>
>>> <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.
>>>
>>> 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:

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Nov 2003 10:40:34 -0500

Paul

	Paul

---

From: Ben Campbell <[email-masked]>
Date: Tue, 11 Nov 2003 09:58:01 -0600

> retransmitting any messages not confirmed on the old one.

OK, so to clarify the bounderies of this discussion, we do not think 
that retransmission within a particular session is useful. This implies 
that duplicate suppression _within_ a session is not particularly 
interesting for its on sake. Do the active participants in this 
conversation agree with this point?

We _are_ however, concerned about how an implementation might _resume_ a 
  session that has died for whatever reason. By _resume_, I mean create 
a new (and unrelated at the protocol level) session that continues the 
conversation. In this case, an implementation might choose to re-send 
content for which receiption on the previous session could not be 
confirmed. If this occurs, it may be interesting to have a cross-session 
duplicate suppression mechanism. There is still open discussion on 
whether this is needed at all, and if so, should it be required or 
optional. We pretty much agree that if we were to do something like 
this, it would involve TR-ID, but there is still open discussion on how 
strong of requirements we would need for uniqueness, and remembering 
past values. Do the active participants in this conversation agree that 
this is the current state of the controversy?

> problems via informal communication.

I would hope that automata would be designed so that duplicates cause no 
harm--but I guess it is hard to guarantee that. I must also point out 
that our primary use case is delivering messages to humans. While we do 
not prohibit automata, we have generally not included requirements that 
are specific to automata processing.

>>>> ..., but retransmissions of old ones would still carry their 
>>>> original TR-ID.
>>>>
>>>> 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:

---

From: Ben Campbell <[email-masked]>
Date: Tue, 11 Nov 2003 09:58:01 -0600

---

From: Aki Niemi <[email-masked]>
Date: Tue, 11 Nov 2003 19:07:01 +0200

ext Ben Campbell wrote:
>> shouldn't be attempted. The issue is retransmission of messages 
>> pending on the old session when switching to a replacement session. 
>> That situation can arise if for instance a relay crashes. In that case 
>> the endpoint may well recover by establishing a new session and 

Agreed.

>  session that has died for whatever reason. By _resume_, I mean create a 
> new (and unrelated at the protocol level) session that continues the 

Yes.

I think the first thing to understand is how the end point deals with a 
failing session. If it tears down the session (i.e., a SIP BYE) in case 
messages time out or a connection is dropped, then resuming a session 
under these conditions is identical to resuming any old message session. 
This suggests some sort of support for message threads, or session 
identifiers, and as you also hint, goes beyond what the TR-ID is 
supposed to do.

Cheers,
Aki

>> response not delivered this will result in a duplicate message. This 
>> can be mitigated somewhat by clarifying conversation between the users 
>> at the two ends.
>>
>>>>>>> reasonable resolution for this counter; x seems as good a value 
>>>>>>> as any. When the counter hits x, it is reset to zero.

---

From: Aki Niemi <[email-masked]>
Date: Tue, 11 Nov 2003 19:07:01 +0200

Agreed.

Yes.

Cheers,
Aki

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Nov 2003 16:51:28 -0500

Yes.

Yes.

> are specific to automata processing.

In the case of automata that know they are talking to other automata I 
agree with you.

I was thinking of the case where one participant is human and another is 
an automaton. The automaton could be either the sender or the recipient.

An example might be a relay the is acting as a recorder. Another might 
be a chat conference mixer that is trying to ensure that everybody in 
the conference hears everything that is said.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Nov 2003 16:51:28 -0500

Yes.

Yes.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Nov 2003 17:28:59 -0500

Aki Niemi wrote:
> failing session.

I agree.

 > If it tears down the session (i.e., a SIP BYE) in case

I had in mind something slightly less drastic than BYE. I had in mind a 
reinvite that establishes a replacement media session. This seems to be 
the right thing to do if the signaling channel is functional but the 
media channel is broken.

If you reestablish the signaling path as well it is more difficult to 
establish a correlation between the old and new media sessions.

I discussed this somewhat earlier in this thread - copy of message 
attached. But there wasn't any discussion on most of that - just this 
part about message retransmission has been discussed.

I think the whole process of recovering from errors (e.g. media errors) 
is worthy of more specification in sip/sipping as well as in simple.

> identifiers, and as you also hint, goes beyond what the TR-ID is 

Perhaps.

	Paul

Subject: Re: [Simple] Comments on message-sessions-02 - reinvite behavior
From: Paul Kyzivat <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Wed, 05 Nov 2003 14:18:19 -0500
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions <simple.ietf.org>

[email-masked] wrote:
> 
> - 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?

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: Tue, 11 Nov 2003 17:28:59 -0500

I agree.

Perhaps.

	Paul

URI again?
second offer?

	Paul