Subject: [NSIS] Comments about draft-hancock-nsis-reliability-00

From: Michael Welzl <[email-masked]>
Date: 06 Oct 2003 10:03:29 +0200

Hi all,

I just read the "Reliability Functions in the NSIS Transport
Layer Protocol" draft; I generally think it is a very good work.
However, having noticed the very short "congestion control"
section, I would like to comment on a few things:

Obviously, some signaling messages have important delay
requirements. To some degree, this is certainly true
for Refresh messages. Same for triggers - we should not
forget that in the (theoretical  :)   ) case of a
full-featured totally QoS-aware network, accounting will
probably be coupled with QoS setup and QoS teardown
messages ... thus, a user will pay more if they are
delayed. I would therefore take the delay requirement
in account for the congestion control section. So here
are my recommendations:

First, I would recommend using a rate-based instead of a
window-based approach; especially over long-delay links,
window based congestion control can lead to a
stop-and-go behavior that would clearly be unwanted.
This does not necessarily lead to a problem with
TCP-friendliness as there are rate-based congestion control
protocols that are TCP-friendly (e.g. RAP).

Second, I would comment on the possibility of limiting
signaling traffic by making it a fraction of the related
data stream. If I remember things correctly, this has
been done for RTCP/RTP...
If, for instance, each node in a network generates only
3 % of signaling traffic, the whole signaling traffic
in the network will always scale linearly with traffic.
I'm not arguing for the use of a "magic number", but this
general signaling property could be mentioned so messages
can scale well, at least within one application. This
may be unnecessary if the NTLP is congestion controlled,
though ...

Third, I would mandate an interface to specify requirements
to the NTLP protocol. Maybe just delay, but maybe
something else too?!

The idea is: if you specify a delay requirement and use
reliable transport, the sender transport protocol can use
aging on its buffer - get rid of a message that would be
transmitted for the 3rd time but has an exceeded delay
limit, thereby freeing space for a new message.

I know that what I propose here doesn't sound like
it could be applied to existing transport protocol
standards. The question is whether this is the
right place for such a "wish list"...

Cheers,
Michael

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

---

From: [email-masked]
Date: Fri, 24 Oct 2003 18:07:45 +0300

Hi Robert,

Jumping in:

> d) is the main point. on the transfer delay front you need pr-sctp
> or home-made partial reliability above dccp (if multiplexing alone
> isn't good enough). 

Well, you could do something at the application layer, set timers
(less than something like 3xRTT) which may mitigate TCP retransission
induced latencies, but I think this would really get ugly quickly ...

> on the congestion response front, i guess the
> difficulty I have is understanding what it actually means for 3448 to be a
> standards track protocol document. if it means that you still need 
> additional standards actions to be allowed to use it in a concrete 
> protocol, then that work would seem to me to be worth doing, but 
> (xref [c] above) i don't think of that work as being NSIS-specific. 
> 
> maybe john would like to comment on that last point.

specifically on Michael's last point:

> > Mechanisms arise from the desire to use something that
> > is not yet available. I can't think of many applications
> > that would need reliable transport with congestion control
> > that would differ from TCP/SCTP - but NSIS appears to be a
> > candidate.

If we want to go this way, it might be nice if someone could
document why NSIS would appear to be a candidate.  I think
I understand where you are going with this, but actually
seeing the reasons down in black & white might clarify things.

thanks,
John