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

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 6 Oct 2003 16:16:33 +0100

hi michael,

see below:

> -----Original Message-----
> From: Michael Welzl [mailto:[email-masked]]
> Sent: Monday, October 06, 2003 09:03
> To: [email-masked]
> Subject: [NSIS] Comments about draft-hancock-nsis-reliability-00
> 
> 
> 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:

[aside: people joining the conversation late might need directing
towards the companion work
http://www.ietf.org/internet-drafts/draft-hancock-nsis-overload-00.txt
which we discussed earlier.]

anyway, i'm glad you liked it.

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

you are right that, even if the decision is made to incorporate
congestion control in the NTLP, choosing the right specific
behaviour is still an important design choice. i see advantages
to using protocols which allow more freedom in selecting 
congestion response (e.g. dccp); maybe you could even 
use TFRC (rfc3448) with sctp (or even tcp).

i think I would see this as an NTLP design issue (or even
implementation issue) rather than a framework issue.

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

aha, a non-magic number ...

this property is an interesting part of the story, but so
far as I can see it can't be relied on always being true.
for example, any threshold could be exceeded during a re-routing
event taking place in the network. therefore we need congestion
control anyway, and so thresholding is then not necessary to 
consider formally.

basically, what we would like to think of is some way to
take advantage of the fact that 'signalling is *normally* 
only a small fraction N% of overall traffic and so should 
never *normally* cause a problem' without trying to define 
different protocol behaviours for 'normally' and 'non-normally'. 
one way to do this would be to point out to network engineers
that they can configure N% of reserved capacity for high 
priority traffic and mark signalling as such; then, provided
you guess right and the signalling traffic really is 'normal'
it will never see any problems. again, this would be an
implementation (or even deployment) issue.

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

this is not unreasonable. many reliable radio L2s have a 'transfer
delay' attribute which can be controlled. again, it is 
to some extent an implementation issue.

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

I think for the NTLP we will do what we can with what
is already available (which is actually quite a lot - I'd
be interested to know the official status of whether TFRC
can be used in reality with TCP or SCTP, however).

The correct place for a wish list is probably somewhere else...

> 
> 
> Cheers,
> Michael
> 
> 
> _______________________________________________
> 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: "Michael Welzl" <[email-masked]>
Date: Mon, 6 Oct 2003 18:07:12 +0200

Hi,

> which we discussed earlier.]

Okay ... I was a bit hesitant to comment at first - I've been
subscribed to NSIS for a while but actually gave up following
all the discussions at a certain point because it just became
too much. Sorry for missing this.

> use TFRC (rfc3448) with sctp (or even tcp).

Hmm... I don't think so (TFRC+SCTP) - see below.
That would be great, though.

> implementation issue) rather than a framework issue.

Okay, I see.

> control anyway, and so thresholding is then not necessary to 

All right - I was approaching a similar conclusion
anyway (need congestion control, therefore unnecessary).

> to some extent an implementation issue.

Hmmm ... is it? Not so sure about this one. It needs
to be specified SOMEWHERE.

> The correct place for a wish list is probably somewhere else...

Well - my intention was to "open things up" a bit;
I disagree that we can already do QUITE a lot. I doubt that
something like the delay-specification interface will ever
see the light of day unless somebody specifies and recommends
it. NSIS is where this functionality would be required, so I
think this is where a recommendation should go.

DCCP is great because it provides a framework for congestion
control mechanisms, but it is for unreliable transport only.
I (sadly) don't know of such a framework for reliable transport,
and I don't think that TFRC could easily be integrated in
either TCP oder SCTP.

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.

Cheers,
Michael