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

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 9 Oct 2003 10:01:38 +0100

hi michael,

[nb with a question to the Chair at the end.]

i concentrate on your last point since it seems to be the open one.

the basic question is a combination of 
a) whether it is necessary to impose transfer delay bounds on reliable
   delivery (i.e. 'deliver in X seconds or tell me you have failed')
b) whether it is necessary to use a reliable transfer mechanism with
   a 'smooth' congestion response like TFRC
c) whether NSIS is unique in these requirements
d) whether they can already be satisfied with existing protocols.

In order:
a) seems to be a 'nice to have if easy' facility; you would need
partial reliability in the transport protocol (e.g. pr-sctp). however,
a lot of the potential problems in this area are solved if you have 
multiplexing which allows relative misordering between streams (like
base sctp does). in any case, whether we need to standardise the 
service interface between NTLP and NSLP to configure such delay bounds
or multiplexing is much less clear to me. I would see it as being at
most accompanying work rather than part of the base specifications.

b) seems to be desirable.

c) i think the answer is 'not really'. at least the timeliness requirement
for signalling messages (which relates to both transfer delay and 
congestion issues) would seem to be common to many other signalling
applications traditionally implemented in SS7 networks. rfc2719 (to me)
points in this direction, for example. of course, there's no harm in 
adding our voice to the requirement (if it is currently unsatisfied).

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

robert h.

> -----Original Message-----
> From: Michael Welzl [mailto:[email-masked]]
> Sent: Monday, October 06, 2003 17:07
> To: Hancock, Robert; 'Michael Welzl'; [email-masked]
> Subject: AW: [NSIS] Comments about draft-hancock-nsis-reliability-00
> 
> 
> Hi,
> 
> 
> > > 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.]
> 
> 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.
> 
> 
> > > 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).
> 
> Hmm... I don't think so (TFRC+SCTP) - see below.
> That would be great, though.
> 
>  
> > i think I would see this as an NTLP design issue (or even
> > implementation issue) rather than a framework issue.
> 
> Okay, I see.
> 
> 
> > > 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.
> 
> All right - I was approaching a similar conclusion
> anyway (need congestion control, therefore unnecessary).
> 
>  
> > > 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.
> 
> Hmmm ... is it? Not so sure about this one. It needs
> to be specified SOMEWHERE.
> 
> 
> > > 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...
> 
> 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
> 

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

---

From: Michael Welzl <[email-masked]>
Date: 09 Oct 2003 11:30:47 +0200

hi,

> d) whether they can already be satisfied with existing protocols.

I agree - that's a very clear and good way to put it.

> most accompanying work rather than part of the base specifications.

I agree in every aspect (in particular, this includes the last two
sentences). I am in the "let's write a recommendation" camp, though.

> b) seems to be desirable.

I agree - but note that to me, the key issue is its rate based nature
rather than it's (still desirable) smoothness.

> adding our voice to the requirement (if it is currently unsatisfied).

I agree (no harm in adding our voice). As a side note, it
recently occured to me that the requirements should be similar
for Grid transport.

> standards track protocol document. if it means that you still need 

Easy answer: a quote from 3448.

Instead
of specifying a complete protocol, this document simply specifies a
congestion control mechanism that could be used in a transport
protocol such as RTP [7], in an application incorporating end-to-end
congestion control at the application level, or in the context of
endpoint congestion management [1].  This document does not discuss
packet formats or reliability.

I am sure that it would be really difficult to integrate TFRC in
TCP oder SCTP - mainly because TFRC is rate-based.

> (xref [c] above) i don't think of that work as being NSIS-specific. 

I think it would be worth doing for the sake of signaling and
Grid transport - an equivalent of DCCP for reliable transport,
if you will, with different (more appropriate) CC mechanisms
to choose from ... but this should be research at this point,
not standardization.

However, as something like this seems to be desirable for NSIS,
I am in favor of writing a recommendation. Otherwise, nobody may
ever want to take up this kind of work...

Cheers,
Michael