Subject: RE: [NSIS] Re: QoS NSLP: ACK flag has no effect?

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 13 Mar 2006 14:36:39 +0100

Hello Roland,

I didn't track it closely but would I be wrong if I say that the QoS 
NSLP was designed not have any topology awareness? If that's true 
and if mixing GIST and NSLP state information would be required 
for a useful NSLP Keep Alive mechanism, it may be better 
to concentrate on  

"Design Options of NSIS Diagnostics NSLP"

and work out a mechanism for re-active NSLP monitoring 
(like PING and traceroute). Would you agree?

Regards,

Rüdiger

RoB|Consequently I would prefer removal of the ACK flag and possibly
|> |provide a simple HELLO mechanism (with adjustable timeouts)
|> |between peers to detect communication failures. I really don't know
|> |what fast reaction an application could undertake due a
|> |transmission/processing failure of a RESERVE message that was
|> |detected by the currently proposed ACK mechanism. -> see below
|> 
RG Such a Hello mechanism may indeed be the better idea. The current 
|> NSLP version seems to be rather stable. Would you propose to 
|> include the Hello mechanism in the current draft or would it be 
|> acceptable to to start working on it in a later version (e.g. 
|> separate document - may be a feature desireable for other 
|> nslps too - or qos nslp version 2)?

RoB
|I think that adding a simple Hello mechanism would be not
|so complex, since overall it would be easier than implementing the
|currently proposed ACK mechanism with retransmissions
|per message. On the other hand we have a problem, because
|information is missing about the identity of the next QoS NSLP peer
|since the latter is managed by GIST and the NLI is currently
|not passed over the API (which makes it also hard to realize summary
|refreshes BTW). So one could think
|about an API extension that allows to pass NLIs from GIST to NSLPs so
|that the NSLP instance is at least able to monitor a mapping from
|sessions or flows to peers/neighbors.
|
|Note that GIST has already a HELLO mechanism per MA though it's primary
|purpose was not to detect failures, but to keep the MA open, 
|right? Thus
|the rate of HELLO messages would be relatively low. Moreover, it will
|not detect the liveliness of the QoS NSLP instance, only of the GIST
|instance. The second issue that we need to decide about is
|the reaction of QoS NSLP when a failure is detected.
|Possibly it can send an Invalidate Routing State to it's own GIST
|instance. This may not help, however, in case the routing and GIST
|is still working correctly. Sending a NOTIFY (but for which peers
|exactly?) would also be an option, but I doubt that this would help
|much.
|
|Regards,
| Roland
|
|
|
|_______________________________________________
|nsis mailing list
[email-masked]
|https://www1.ietf.org/mailman/listinfo/nsis
|

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 13 Mar 2006 18:28:42 +0100 (MET)

Hi Rudiger
Hi Roland

Rudiger, are you refering tothe draft:
                   draft-fu-nsis-diagnostics-nslp-01?

If yes, then I agree with you!

Roland, please note that the functionality associated with the ACK flag
can be used
by QoS models to give the possibility to a peer to request the imediate
generation of  a Response from its neighbouring peer.
I am in favour of keeping this functionality.

Best Regards,
Georgios

---

From: Roland Bless <[email-masked]>
Date: Thu, 16 Mar 2006 09:51:31 +0100

Hi Georgios,

> If yes, then I agree with you!

Ok, the problem is that this diagnostics nslp is
separated from the QoS nslp and other nslps,
therefore results may be different.

> generation of  a Response from its neighbouring peer.

Yep, but the way the ACK mechanism was previously
specified made no sense. A received confirmation or a
missing confirmation had no effect. That's why I proposed
some retransmission mechanism within QoS NSLP. Maybe that
was too ambitious and wasn't required actually (that's why
I asked exactly about the original problem the ACK mechanism
tried to solve!).

> I am in favour of keeping this functionality.

Georgious, you may be in favor of keeping it, but are there
technical reasons?
Now (after Ruediger is probably satisfied with a different solution
and Georgious wants this explicit confirmation)
I see different options:

1.) Provide a generic ACK mechanism for QoS models only.
    Thus, retransmissions etc. are QoS model specific.
    This is was more or less defined by the versions before -10.
    However, in this case we need to specify the actions,
    i.e., the QoS model decides when the ACK flag is set,
    the receipt of a RESPONSE solicited by an ACK should
    be indicated to the QoS NSLP application/QoS model, and,
    the QoS model may retransmit a RESERVE in case no RESPONSE
    was received.

2.) Use QoS NSLP internal semantics as currently defined,
    i.e. QoS NSLP will trigger retransmissions.

In either case I suggest to remove the statement:
"This flag SHOULD be set on transmission by default."
to
"This flag MAY be set on transmission".

Currently, I prefer option 1.) if the ACK functionality is
really required.

Regards,
 Roland

-- 
Dr. Roland Bless -- WWW: http://www.tm.uka.de/~bless
Institut für Telematik, Universität Karlsruhe (TH), Germany
Zirkel 2, D-76128 Karlsruhe -- Geb. 20.20, 3.OG, Raum 358
Tel.: +49 721 608-6413 Fax: +49 721 608-6789

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 16 Mar 2006 10:04:05 +0100 (MET)

Hi Roland

You are right!
The ACK is not needed at all!
In case a node expects a RESPONSE it may include a RII if there is no RII
carried by the incoming RESERVE.

Thus I also support the proposal of removing completely the ACK
functionality!

Best Regards,
Georgios

Best Re

---

From: Roland Bless <[email-masked]>
Date: Thu, 16 Mar 2006 10:21:21 +0100

Hi Georgios,

> carried by the incoming RESERVE.

Yes, exactly.

> Thus I also support the proposal of removing completely the ACK

Ok, that was option 3.) as proposed in an earlier mail :-)

Regards,
 Roland

---

From: Xiaoming Fu <[email-masked]>
Date: Fri, 17 Mar 2006 00:22:56 +0100

Hi,

There could be several non-competing options (to apply in different 
scenarios):

A. making trigger messages be reliable (which could be very useful, as
concluded by [1])

B. making usual refreshes be reliable (which could be not as useful as A)

C. making reduced overhead extension refreshes to be reliable (which
will be useful per RFC2961/[2]).

D. making removal messages be reliable  (which could be useful, as
concluded by [1])

"Reliable" above means whether one needs an explict Response to be sent
from the recipient upon receipt of the corresponding
trigger/refresh/removal.

My view is that unreliable transmission would suffice B; for A and C
reliability SHOULD/MUST be made; for D reliability MAY be made. Relying
on the existence of RII to determine whether to give a response is 
probably not a typical behavior from my personal limited understanding 
of other protocols.
[1] P. Ji, Z. Ge, J. Kurose, and D. Towsley, A Comparison of Hard-State
and Soft-State Signaling Protocols, SIGCOMM 2003.
[2] P. Pan and H. Schulzrine, Staged Refresh Timers for RSVP, Global
Internet 1997.
Cheers,
Xiaoming

---

From: Jukka MJ Manner <[email-masked]>
Date: Sun, 19 Mar 2006 21:44:17 +0200 (EET)

(trying to follow up on the latest comments)
   
Hi,
 
Say you are a mobile node, and your next peer is the access router. Having
TCP there as GIST transport is a bad idea. Yet, I'd still like to know 
immediately that my message was received by the next AR. 

I was re-reading the QoS NSLP spec to see what is actually said about the
RII, and it is not really clear, who actually replies to the RII. It
should be the QNR, right, but this is not very well said. Thus, if you
would use the RII to request a confirmation for your RESERVE, you need to
wait up the e2e RTT before you know, whether your RESERVE ever got to the
QNR.

I'd rather use Roland's second option, that is, the ACK-flag should not be
used by default (as it creates a lot of overhead), but only in special
cases. So, a MAY would be fine.

Jukka

---

From: Roland Bless <[email-masked]>
Date: Sun, 19 Mar 2006 22:08:22 +0100

Hi Jukka,

> TCP there as GIST transport is a bad idea. Yet, I'd still like to know 

Ok, I'm not totally sure that we should try to put
reliability mechanisms into QoS NSLP itself. One early design decision
was to don't do it again, but to let us re-use the well-known
transport protocols below GIST.

> immediately that my message was received by the next AR. 

Ok, for what purpose (I still want to know what problem
should be solved by this ACK)? So that you know that your message
was not dropped and is on the way? This would be more transport
related. We also had other reasons for the ACK:
know that the other QoS NSLP instance has received it and know that
it's alive etc. The main question is: what do you do if you did not
receive that confirmation? Can you do anything about it? In case of
loss it would be retransmission, in case of a link/node/transport
failure there will be not so many options available.

> should be the QNR, right, but this is not very well said. Thus, if you

In case we have this rerouting scenario the replying node may
be the crossover node and not the QNR.

> wait up the e2e RTT before you know, whether your RESERVE ever got to the

Is there another possibility to do so? A confirmation from the QNR
would take an e2e RTT any case or am I missing something?

> cases. So, a MAY would be fine.

That wasn't exactly option 2 (see below). The SHOULD->MAY change
was meant for both options (though one may discuss a SHOULD
in case of unreliable transport). In case we need a confirmation
I'm still for my first option, namely to keep the ACK, but
to don't do retransmissions within QoS NSLP itself.
Option 2 would make sense in case we use unreliable
transport and want simple reliability (like SIP, RTSP,
etc.).

%1.) Provide a generic ACK mechanism for QoS models only.
%    Thus, retransmissions etc. are QoS model specific.
%    This is was more or less defined by the versions before -10.
%    However, in this case we need to specify the actions,
%    i.e., the QoS model decides when the ACK flag is set,
%    the receipt of a RESPONSE solicited by an ACK should
%    be indicated to the QoS NSLP application/QoS model, and,
%    the QoS model may retransmit a RESERVE in case no RESPONSE
%    was received.
%
%2.) Use QoS NSLP internal semantics as currently defined,
%    i.e. QoS NSLP will trigger retransmissions.

Regards,
 Roland

---

From: Roland Bless <[email-masked]>
Date: Sun, 19 Mar 2006 22:47:40 +0100

Hi Xiaoming,

> will be useful per RFC2961/[2]).

I guess that this is more related and more essential
to _summary_ refreshes which we currently don't have.

> from the recipient upon receipt of the corresponding

Ok, but who is "the recipient"? In case of the RESPONSE from the far
end it's usually the QNR, in case of the ACK it's the next QNE, maybe
for different purposes.
Consider the action that should be taken on a missing ACK:
in case of unreliable transport you probably can recover a
packet loss by simply retransmitting the request again; but in case you
are already using reliable transport, you may indicate a failure
after some timeout.

> reliability SHOULD/MUST be made; for D reliability MAY be made. 

Just wanted to note that a RESPONSE may also be lost
in case of unreliable transport, and, as already said:
I guess that reliable transport is more the task of GIST
than of QoS NSLP.

> Relying

You are right. I would prefer to always get a RESPONSE (from the QNR
or far end).
The ACK mechanism is a different thing, because it is only triggering
a response from the direct peer. It would help a lot if we could
actually write down the requirements. From the past discussions I
have the impression that people want to achieve totally different things
with the defined retransmission mechanisms. Thus it would be good to
clearly describe the problem(s) we want to solve. Short summary:
Ruediger: wants liveliness check
Georgious: wants some confirmation (for what purpose?)
Jukka: wants to recover loss(?) in case of unreliable
transport (wants to avoid using TCP for mobile nodes...)

Regards,
 Roland

---

From: Xiaoming Fu <[email-masked]>
Date: Mon, 20 Mar 2006 13:54:09 +0100

Hi Roland,

> to _summary_ refreshes which we currently don't have.
Besides Srefreshes (supported in current text 3.2.5), options in 
RFC2961 can be also useful:
- reliability by hop-by-hop acknowledgement (context of ACK discussions 
here)
- bundled messages: currently we don't have (?).

> end it's usually the QNR, in case of the ACK it's the next QNE, maybe

- Per-hop ACK is probably necessary, when the reliable GIST transport is 
used.
- Response from the far end should be always good to have, in order to 
have a reasonable reliability in QoS NSLP level.

> are already using reliable transport, you may indicate a failure

Yes I agree we probably need to let the reaction to a receiving ACK to 
depend on used GIST property.

> I guess that reliable transport is more the task of GIST

Maybe QoS NSLP could have its own "reliability" by allowing QNI/R to be 
more consistent with their own engines.
> You are right. I would prefer to always get a RESPONSE (from the QNR
We are inline with each other here. :)

Regards,
Xiaoming

---

From: Roland Bless <[email-masked]>
Date: Mon, 20 Mar 2006 17:24:59 +0100

Hi Xiaoming,

> Besides Srefreshes (supported in current text 3.2.5), options in RFC2961

Sorry, but 3.2.5 is about _Reduced_ Refresh which is a little bit
different from a summary refresh. The former only leaves out the QSPEC,
the latter would refresh several reservations/sessions with only one
packet. Currently, we don't have such a feature => (Would it be
desirable?)

> can be also useful:

The main motivation for ACKing was packet loss of non-refresh messages
and too long timeouts for faster retransmission, quotes from RFC 2961:

   The reliability and latency problem occurs when a non-refresh RSVP
   message is lost in transmission.  Standard RSVP [RFC2205] recovers
   from a lost message via RSVP refresh messages.  In the face of
   transmission loss of RSVP messages, the end-to-end latency of RSVP
   signaling is tied to the refresh interval of the node(s) experiencing
   the loss.  When end-to-end signaling is limited by the refresh
   interval, the delay incurred in the establishment or the change of a
   reservation may be beyond the range of what is acceptable for some
   applications.

...

   The ACK_Desired flag is set when the MESSAGE_ID object generator
   wants a MESSAGE_ID_ACK object sent in response to the message.  Such
   information can be used to ensure reliable delivery of RSVP messages
   in the face of network loss.  Nodes setting the ACK_Desired flag
   SHOULD retransmit unacknowledged messages at a more rapid interval
   than the standard refresh period until the message is acknowledged or
   until a "rapid" retry limit is reached.  Rapid retransmission rate
   MUST be based on the exponential exponential back-off procedures
   defined in section 6.  The ACK_Desired flag will typically be set
   only in trigger messages.  The ACK_Desired flag MAY be set in refresh
   messages.  Issues relate to multicast sessions are covered in a later
   section.

However, I guess that we simply could use our underlying reliable
GIST transport to avoid that.

> - bundled messages: currently we don't have (?).

IIRC signaling message bundling is supported by SCTP.
If you want that, you probably want to use GIST with SCTP.
This is, however, a little bit different from bundling within QoS NSLP,
because we still have the overhead of multiple GIST and QoS NSLP
headers.

> - Per-hop ACK is probably necessary, when the reliable GIST transport is

??? do you mean _un_reliable ??

> have a reasonable reliability in QoS NSLP level.

And feedback about the actually reserved resources, etc.

> more consistent with their own engines.

Hmm, therefore I would propose to add that ACK flag,
but let the corresponding  reaction up to the QoS model/application.

Regards,
 Roland

---

From: Xiaoming Fu <[email-masked]>
Date: Mon, 20 Mar 2006 17:39:40 +0100

Hi Roland,

> packet. Currently, we don't have such a feature => (Would it be

I interpreted Srefreshes as method using Message_ID to reduce refresh 
message size. Ok.
> GIST transport to avoid that.

Agreed/
> because we still have the overhead of multiple GIST and QoS NSLP

Will bundling in the GIST level make GIST too involved with NSLP 
semantic?
> ??? do you mean _un_reliable ??
Sorry, my typo.
> And feedback about the actually reserved resources, etc.

Yup.
> but let the corresponding  reaction up to the QoS model/application.
Also my feeling. in short:
- Whether one needs an ACK: determined by GIST property (reliable v.s 
unreliable)
- How to react on received ACKs: determined by QoSM/higher.
Xiaoming

---

From: "Robert Hancock" <[email-masked]>
Date: Mon, 20 Mar 2006 13:10:21 -0600

hi all,

some issues about the interactions between nslp and gist also 
occurred to me while reading the draft. specifically:

*) in 5.2.4, the correct rules for the qos-nslp do depend on 
whether GIST is being used for reliable transport or not. but in 
either case, I don't think that initialising the RTO estimate using
transport layer algorithms is valid, since the ACK at the NSLP
level also has to take account of application level interactions
(e.g. policy checks) for which such estimates are invalid. 
indeed, this was one of the main motivations for supporting
reliable transport in GIST: to optimise transport layer 
retransmission behaviour better than the application will ever
be able to, allowing the application to concentrate on handling
application layer timeouts correctly. 

if GIST reliable transport is being used, I think there is a good
case for saying that if GIST reports a message delivery failure
then the NSLP should just give up as a fatal error condition. only
if unreliable transport is being used should the application try
to do something more clever. but I would then question why you would
set the Ack flag and request unreliable transport.

*) similarly, i'm not sure that 5.3.4 is fully correct. at least,
you could say that if reliable transport is being provided by
GIST, then this sort of special slew handling is unnecessary;
the slew handling algorithms are only there to handle lost messages.
you could simply say 'if you want to use unreliable transport you 
must keep the refresh period fixed for a given period', which would
simplify this section quite considerably.

*) there is some discussion below about bundling. to avoid any
doubt, GIST will bundle any messages sent over the reliable
transport if it can work out they are to the same peer. (in 
particular, it will do this with TCP, you don't need SCTP.)
if you want message summarisation as well, that could be done
either at the NSLP level (invisible to GIST), or it could be
added as a protocol option to GIST, in which case one could 
imagine rather efficient solutions which exploited redundancy
between GIST and NSLP messages as well as between successive
messages. (I have occasionally wondered about writing a 2-3 page
specification for sigcomp/RFC3320 as a messaging association
protocol. Maybe something for the new work discussion.)

r.

> -----Original Message-----
> From: Roland Bless [mailto:[email-masked]] 
> Sent: 20 March 2006 10:25
> To: Xiaoming Fu
> Cc: nsis
> Subject: Re: [NSIS] Re: QoS NSLP: ACK flag has no effect?
> 
> 
> Hi Xiaoming,
> 
> >>> B. making usual refreshes be reliable (which could be not 
> as useful
> >>> as A)
> >>>

---

From: Roland Bless <[email-masked]>
Date: Mon, 20 Mar 2006 21:49:46 +0100

Hi Robert,

> (e.g. policy checks) for which such estimates are invalid. 

You are right that the current proposed RTT estimate includes all
processing within the QoS NSLP and also above it. Indeed, it depends
on what you're trying to achieve with that ACK mechanism (that's why
I'm insisting so stringent on a precise problem statement). If the
purpose of the ACK mechanism is to confirm state installation (including
policy data verification, admission control test etc.) then
the estimate simply expresses the expected average processing time
including transport. But if, as you noted below, the primary objective
is to recover from packet loss, this is far from being optimal.

> application layer timeouts correctly. 

Agreed.

> set the Ack flag and request unreliable transport.

Yes, that's what I repeatedly said. Jukka mentioned that TCP
is to heavyweight for mobile nodes. Then, I would say, simply
add another suitable transport protocol to GIST. Moreover, you could
request unreliable transport, but GIST may switch to reliable
transport without notice (due to fragmentation) and then you end
up with double ACKing...

> GIST, then this sort of special slew handling is unnecessary;

Yep. I'm feeling uncomfortable with the current 5.2.4 section.

> simplify this section quite considerably.

I'm not quite sure that I get your point.

> particular, it will do this with TCP, you don't need SCTP.)

You are right, messages are probably queued and send out
together...simply forgot that :-)

> either at the NSLP level (invisible to GIST), or it could be

IMHO this is not easily possible: At NSLP level, peer identities
are not known anymore, so you could not find out which reservations
have the same peer (currently it is not required that an SII handle
for different MRIs is the same for the same peer).

> protocol. Maybe something for the new work discussion.)

Good.

Regards,
 Roland

---

From: "Robert Hancock" <[email-masked]>
Date: Wed, 22 Mar 2006 10:30:40 -0600

hi roland,

> I'm not quite sure that I get your point.

the problem with slew and unreliable transport is that if you send a message
with an extended refresh period which is lost then
- the sender increases the time between refresh messages (according to the
new period)
- the receiver still expects more rapid refresh messages (according to the
old period)
- the receiver is likely to drop the session (according to the "three
dropped messages and you're out" rule)

there are two solutions here (apart from the slew handling algorithms):
- make sure the refresh gets delivered
- don't change the refresh period

r.

---

From: Roland Bless <[email-masked]>
Date: Wed, 22 Mar 2006 19:29:01 +0100

> - don't change the refresh period

You're right. I guess we got it wrong, because
the problem we were trying to solve wasn't quite clear.
Mixing up retransmissions for reliability with state installation
confirmation seems to be a bad idea. So I'm still not quite
sure what is required.

However, I could think of something like a "provisional"
response if people want to get sure that their message
was received. In this case
the application may ask for this response which is sent as
soon as the message was received by the other peer (so no
confirmation of state installation and no advanced NSLP
processing). This may induce a security problem, because then
even unauthorized requests may generate a response. Further
reactions like retransmission should depend on the application.
Nevertheless, I guess it's not useful to discuss solutions
for not exactly specified problems and we need to discuss
first the general reliable transmission aspects. I have no problem
to use the normal reliable GIST transport, however, other people
seem to like the idea of using an unreliable protocol like UDP
and then adding a simple retransmission mechanism above (like in SIP
over UDP). I'm not sure that this is covered by the design decisions
for NTLP/NSLP we made once.

Regards,
 Roland

---

From: "Robert Hancock" <[email-masked]>
Date: Thu, 23 Mar 2006 05:59:46 -0600

hi,

for the record, i'm highly sceptical about the idea of a 
'mini-tcp' for constrained hosts. if it was possible to
achieve something with any useful functionality that was
significantly simpler than tcp, i believe we would have it
already, and then we could invoke it within GIST. I can 
certainly think of someone who I guess would not regard the 
case of adding reliability to SIP over UDP as a good 
role model to follow.

Brian Carpenter made the same point when reviewing the pre-WG GIMPS:
> I certainly think
> Henning is correct to consider using either a reliable transport
> or not; everyone who tries to bypass TCP ends up partially
> recreating it.

and there was BoF on the general topic at ietf#43; from Harald
Alvestrand's notes
"One BOF called RUTS (I forget why) explored why people used UDP protocols.
A most entertaining discussion of NFS was what I got to hear; explaining how
they eventually had added almost every feature of TCP to their UDP-based
implementation, and then decided to simply switch to TCP.....whenever you
have something more complex than an unloaded LAN, it seems that TCP just
behaves better."

there is a much wordier analysis at
http://www.watersprings.org/pub/id/draft-hancock-nsis-reliability-00.txt

r.

> Sent: 22 March 2006 12:29
> To: Robert Hancock
> Cc: nsis

---

From: <[email-masked]>
Date: Thu, 23 Mar 2006 14:06:22 +0200

Hi all,

I strongly agree with Robert on this.  I had dinner with TSV & RAI
ADs and was told that allowing SIP to support UDP was one of the
worst mistakes they made.  It seems that SIP deployments are having
major problems with fragmentation, for example, and people are now
doing creative things to try to fix it.

My feeling is that TCP is far from a burden for modern hosts, IMO.

John

>From: ext Robert Hancock [mailto:[email-masked]] 
>Sent: 23 March, 2006 14:00
>To: 'Roland Bless'
>Cc: 'nsis'
>Subject: RE: [NSIS] Re: QoS NSLP: ACK flag has no effect?
>
>hi,
>
>case of adding reliability to SIP over UDP as a good role 
>model to follow.
>
>> Henning is correct to consider using either a reliable transport or 
>> not; everyone who tries to bypass TCP ends up partially 
>recreating it.
>
>Alvestrand's notes "One BOF called RUTS (I forget why) 
>explored why people used UDP protocols.
>A most entertaining discussion of NFS was what I got to hear; 
>explaining how they eventually had added almost every feature 
>of TCP to their UDP-based implementation, and then decided to 
>simply switch to TCP.....whenever you have something more 
>complex than an unloaded LAN, it seems that TCP just behaves better."
>
>> You're right. I guess we got it wrong, because the problem we were 
>> trying to solve wasn't quite clear.
>sure what 
>> is required.
>> response if people want to get sure that their message was received. 
>> In this case the application may ask for this response which is sent 
>> as soon as the message was received by the other peer (so no 
>> confirmation of state installation and no advanced NSLP processing). 
>> This may induce a security problem, because then even unauthorized 
>> requests may generate a response. Further reactions like 
>> retransmission should depend on the application.
>> Nevertheless, I guess it's not useful to discuss solutions for not 
>> exactly specified problems and we need to discuss first the general 
>> reliable transmission aspects. I have no problem to use the normal 
>> reliable GIST transport, however, other people seem to like the idea 
>> of using an unreliable protocol like UDP and then adding a simple 
>> retransmission mechanism above (like in SIP over UDP). I'm not sure 
>> that this is covered by the design decisions for NTLP/NSLP we made 
>> once.
>> 
>> Regards,
>>  Roland
>> 
>
>

---

From: Roland Bless <[email-masked]>
Date: Thu, 23 Mar 2006 16:02:10 +0100

Hi Robert,

> case of adding reliability to SIP over UDP as a good 

I fully agree with it. Thanks for providing the following pointers.
Regards,
 Roland

---

From: Roland Bless <[email-masked]>
Date: Thu, 23 Mar 2006 16:10:41 +0100

> doing creative things to try to fix it.

Good, that's what I wanted to hear.

> My feeling is that TCP is far from a burden for modern hosts, IMO.

Great, I fully agree with this.
 Roland

---

From: Roland Bless <[email-masked]>
Date: Thu, 23 Mar 2006 17:40:04 +0100

Hi John

> My feeling is that TCP is far from a burden for modern hosts, IMO.

So a consequence would be to rule out the ACK mechanism for
transport reliability. Good. I would then recommend to remove
the ACK mechanism completely unless someone speaks up to keep
it, stating the problem it should solve.