Subject: thoughts on reiiable transport RE: [NSIS] Reliable Transport for NTLP

From: [email-masked]
Date: Tue, 15 Jul 2003 11:28:32 +0300

Hi all,

Not meaning to pick on Roland specifically, but his comment:

> I think Henning mentioned the "SIP experience" several times and the
> current discussion reminds me somehow of it...   

Made me do a little thinking on this subject.

I've taken Henning's comment on SIP more to mean that supporting multiple
transport protocols are difficult.  This is why I want to see more details
on how to support multiple transport.  Additionally, I thought that
Henning's earlier comments with regards to SIP & reliable were more along
the lines of, if you are going to do fragmentation, congestion control,
etc. it is better to re-use existing transport rather than rolling your
own mechanisms.  

However, some comments in the WG yesterday seemed to be saying, for example, 
TCP does functionality x, y & z so let's use this. I believe Melinda was 
attempting to suggest that maybe functionality x & y are not needed and
maybe thinking about z is needed.  Stating many protocols use TCP,
so why are x, y & z problems seems not to be a helpful line for 
discussion.

John

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

---

From: Roland Bless <[email-masked]>
Date: Tue, 15 Jul 2003 11:13:35 +0200

On Tue, 15 Jul 2003 04:55:14 -0400 Henning Schulzrinne <[email-masked]> wrote:

> The SIP experience was that some thought that only UDP support would be 
> necessary. The tendency has been that the problems that seemed minor 
> (congestion, fragmentation) became rather annoying as things progressed 
> and as a more complete system was built.

Thanks Henning, I was refering to exactly this fact.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 15 Jul 2003 04:55:14 -0400

> transport protocols are difficult.  This is why I want to see more details

This needs to be qualified a bit, I think. The support for multiple 
protocols is not particularly difficult. For example, adding SCTP 
support to TCP was fairly trivial. The slightly difficult part was 
trying to achieve both low-latency end-to-end reliability and per-hop 
reliability. (The difficulty is not in the protocol, but to make sure no 
extra work is being done, i.e., that you don't end up retransmitting 
across a TCP connection.) If we had done purely hop-by-hop (that is, 
proxy-to-proxy or UA-to-proxy) mechanisms, this would have been fairly 
easy. SIP had special concerns that lead to this design (forking and 
human "end systems"), which don't apply here.

Thus, one "lesson" is to do things only once or at different 
time-scales. It's no problem to have a long-term recovery mechanism 
(say, at RSVP 2205 timescales) that primarily deals with system and 
network failures and a short-term one dealing with packet loss. That's 
roughly the 2205 + 2916 combination. I happen to think we can improve 
upon the performance of the latter mechanism, while making it simpler 
(since we're not bolting it on after the fact).

> etc. it is better to re-use existing transport rather than rolling your

Certainly - any attempts to try to this at higher layers seems to end up 
re-inventing the same mechanisms while often lacking the access to the 
lower-level tools.

> so why are x, y & z problems seems not to be a helpful line for 

Some of us have different opinions on these requirements and claim to 
have described clear use cases for these items. Maybe that's not been 
clear or convincing enough, but I don't think it helps to deny that the 
attempts have been made or not at least to refer to those discussions.