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

From: [email-masked]
Date: Thu, 6 Nov 2003 11:31:48 +0200

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, November 05, 2003 9:22 PM
> To: Khartabil Hisham (NMP-MSW/Helsinki)
> Cc: [email-masked]
> Subject: Re: [Simple] Comments on message-sessions-02 - message retry
> 
> 
> [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.

If I understand you correctly, you are suggesting that if a message fails with a 500 or a timeout, then we create a new session and try resending it there? If so, then I think I disagree. I think there should not be any retransmission at all. The end user can choose to send the message again, after he learns that the message did not really get there.

Also, you really want to tie TR-IDs across sessions?

Regards,
Hisham

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

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

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 10 Nov 2003 22:35:47 -0000

This does seem like a cleaner solution.  I personally don't see any problems using this approach .
 
-----Original Message----- 
From: Ben Campbell [mailto:[email-masked]] 
Sent: Mon 10/11/2003 21:55 
To: Aki Niemi 
Cc: Paul Kyzivat; [email-masked]; [email-masked] 
Subject: Re: [Simple] Comments on message-sessions-02 - message retry

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

�jezf��)��+-J)��螵�+�m����5��_��?�������+-�w��Ȧ�W

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 10 Nov 2003 22:35:47 -0000

---

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

> Sent: Tuesday, November 11, 2003 12:27 AM
> To: Ben Campbell
> Cc: Niemi Aki (NMP/Helsinki); Khartabil Hisham (NMP-MSW/Helsinki);
> [email-masked]
> 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,
> >>
> >> 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.
> > 
> > 
> >> 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: [email-masked]
Date: Tue, 11 Nov 2003 18:07:02 +0200

> From: ext Ben Campbell [mailto:[email-masked]]
> Sent: Tuesday, November 11, 2003 5:58 PM
> To: Paul Kyzivat
> Cc: Khartabil Hisham (NMP-MSW/Helsinki); Niemi Aki (NMP/Helsinki);
> [email-masked]
> > 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.
> 
> 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?

Yes.

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

Retransmission of any kind is harmful if long messages are being sent. Ignoring the issue of automata, I still vote for not doing transmission of any kind (over the same or different sessions).

/Hisham

> 
> > 
> > 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.
> > 
> 
> 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.
> 
> >     Paul
> > 
> >     Paul
> > 
> > Ben Campbell wrote:
> > 
> >> 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.
> >>
> >>> 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:
> >>>>>> The current draft reads to me that the TR-ID should be 
> >>>>>
> >>>>>
> >>>>
> >>>> unique within a
> >>>>
> >>>>> 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
> >>>>
> >>>>>> Having said that, I think TR-ID is not working to its full 
> >>>>>
> >>>>>
> >>>>
> >>>> potential,
> >>>>
> >>>>>> Let's make TR-ID a simple counter. Each session starts 
> >>>>>
> >>>>>
> >>>>
> >>>> from zero, and
> >>>>
> >>>>> 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
> >>>>
> >>>>> overloaded, but recovers well enough to process TR-ID 3, 
> >>>>
> >>>>
> >>>>
> >>>> then TR-ID 2
> >>>>
> >>>>> 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,
> >>>>
> >>>>>>> If TR-ID is not required to be unique across sessions, 
> >>>>>>
> >>>>>>
> >>>>
> >>>> and you allow
> >>>>

---

From: [email-masked]
Date: Tue, 11 Nov 2003 18:07:02 +0200

Yes.

/Hisham

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 27 Nov 2003 09:14:38 -0000

<<comments in-line>>

>From: Paul Kyzivat [mailto:[email-masked]]
>Sent: 07 November 2003 23:10
>To: Ben Campbell
>Cc: [email-masked]; [email-masked]
>inline...
>>>>    - 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
>>> establishing a replacement media session and then retrying the
message
>> 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.
>
>I agree it should be an application issue whether to do this.
>
> > 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.
>
>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.

[Chris Boulton]This seems by far the most straight forward solution.  I
certainly think that we should encourage uniqueness across streams - I
see this causing problems.  As for the amount of time that a TRID is
'remembered' - couldn't it just be for the duration of the SIP dialog? 

>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.
>>
>> I assume the weak mechanism to which you refer is the TR-ID approach
>> mentioned above. See my comments above.
>
>yes.
>
>	Paul
>
>
>_______________________________________________________________________
_
>This email has been scanned for all viruses by the MessageLabs Email
>Security System. For more information on a proactive email security
>service working around the clock, around the globe, visit
>http://www.messagelabs.com
>_______________________________________________________________________
_

________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
________________________________________________________________________

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 27 Nov 2003 09:14:38 -0000

<<comments in-line>>

content
message
create
to
uniqueness
error

be
_
_

---

From: "Chris Boulton" <[email-masked]>
Date: Fri, 28 Nov 2003 16:55:51 -0000

>Sent: 10 November 2003 17:09
>To: Paul Kyzivat
be
>> helpful. Instead, we can simply introduce an error response to be
used
error
be
>by TR-ID collisions. This seems bad to me.
[Chris Boulton] I totally agree.

_
_

---

From: "Chris Boulton" <[email-masked]>
Date: Fri, 28 Nov 2003 16:55:51 -0000

be
used
error
be

_
_