Subject: RE: [NSIS] Reliable Transport for NTLP

From: Attila Báder (ET/ETH)<[email-masked]>
Date: Thu, 24 Jul 2003 11:07:40 +0200

Hi All,

My view is related to our stateless (or reduced states) concept in which we do not distinguish individual flows in interior nodes. We rely on reserve, refresh, tear messages, which add or remove resources in reasonable timing. Hop-by-hop retransmission or fragmentation/reassembling in the domain affect negatively the performance of this kind of NSLP. What our NSLP provides is actually edge-to-edge reliability. 

On the other hand, I think, if pear-to-pear reliability is desirable for other applications it is reasonable to be part of NTLP as an option. 

Regards, Attila

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Hancock, Robert
> Sent: Wednesday, July 23, 2003 11:32 PM
> To: 'Henning Schulzrinne '; ' Attila Báder (ET/ETH) '
> Cc: Hancock, Robert; [email-masked] '
> Subject: RE: [NSIS] Reliable Transport for NTLP
> 
> 
> Hi Henning,
> 
> As usual, there is more than one question here.
> 
> I'm also not a fan of relying on only 'end-to-end'
> (in the sense of first-NSIS-node-to-last-NSIS-node)
> reliability.
> 
> However, even if we agree that a signalling application
> needing reliability needs it between (say) adjacent NSLP
> peers rather than simply end-to-end, there is still the 
> question of which layer it should be provided at (NTLP
> or within each application).
> 
> I argued in my email to Scott that there were good
> reasons why this functionality should be part of the 
> NTLP. I'd be interested in views on whether those
> arguments were valid (or what other arguments were 
> valid). I think the practical consequence would be that
> some form of reliable message transport (*) would be
> mandatory functionality in the NTLP, optional for an
> NSLP to invoke on a message-by-message basis.
> 
> cheers,
> 
> r.
> 
> (*) coupled ideally with some form of express routing
> to bypass intermediate nodes between the NSLP peers.
> 
> -----Original Message-----
> From: Henning Schulzrinne
> To: "Attila Báder (ET/ETH)"
> Cc: Hancock, Robert; [email-masked]
> Sent: 23/07/2003 18:25
> Subject: Re: [NSIS] Reliable Transport for NTLP
> 
> At least from our implementation experience with a vaguely related 
> protocol, the additional complexity of such choice is very 
> modest (a few
> 
> tens of lines of code and an additional table).
> 
> As I've said in an earlier message, I'd like to challenge 
> advocates of 
> only offering only end-to-end reliability to address even the simple 
> issue of what RTT estimate to pick if nodes perform anything 
> but trivial
> 
> forwarding. NSIS nodes are not just dumb packet routers with 
> microsecond
> 
> latency...
> 
> 
> Attila Báder (ET/ETH) wrote:
> 
> > Hi Robert and All,
> > 
> > I also think the question is very fundamental. Since NSIS addresses
> wider range of applications, most probably there will be NSLPs which
> like to use retransmission-like reliability, while other 
> concepts intend
> to support reliability like RSVP does. Certainly both have advantages
> and disadvantages and it depends on the applications.
> > 
> > In my view this latter is closer to the original concept of soft
> states and using RSVP as a base. Our stateless concept for 
> example needs
> the simplest transport as possible and it may be reasonable for other
> NSLPs as well. I am afraid that if retransmission is a common 
> service of
> NTLP, even if it is optional to use, it introduces unnecessary
> implementation complexity.
> > 
> > The question can be put in another way as well: Should NTLP have
> optional features that can be invoked by different NSLPs, or 
> NTLP should
> be a protocol supporting common basic features and optional 
> feature are
> only in NSLP? I do not remember if we had a consensus regarding this
> question.
> > 
> > Best regards,  Attila
> 
> 
> _______________________________________________
> 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: "Thanh Tra LUU" <[email-masked]>
Date: Thu, 24 Jul 2003 11:31:18 +0200

hi Attila,

I am a fan of E2E reliable delivery but I don't agree with your idea.
If TCP is used, reliable delivery is always used even though your
signaling application needs it or not. It belongs to lower layer and
there is no relationship between stateless attribute and lower layer
here.

I feel that TCP is something too 'solid' and not flexible. If TCP is
used, signaling application must bear all the security attacks of this
protocol (e.g. SYN TCP attack). It will be easier for attack a
signaling aware node because a packet can be sent from a distant host
to a signaling node on the data path without Router Alert Option being
set.

I'll try to find some more arguments for using IP or UDP as a lower
layer of NTLP.

Nary Tra,
ENST, Paris

----- Original Message -----
From: "Attila Báder (ET/ETH)" <[email-masked]>
To: "Hancock, Robert" <[email-masked]>; "'Henning
Schulzrinne '" <[email-masked]>; "Geib, Ruediger"
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 24, 2003 11:07 AM
Subject: RE: [NSIS] Reliable Transport for NTLP

Hi All,

My view is related to our stateless (or reduced states) concept in
which we do not distinguish individual flows in interior nodes. We
rely on reserve, refresh, tear messages, which add or remove resources
in reasonable timing. Hop-by-hop retransmission or
fragmentation/reassembling in the domain affect negatively the
performance of this kind of NSLP. What our NSLP provides is actually
edge-to-edge reliability.

On the other hand, I think, if pear-to-pear reliability is desirable
for other applications it is reasonable to be part of NTLP as an
option.

Regards, Attila

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 24 Jul 2003 09:44:13 -0400

Nary Tra,

in order to make progress in this WG, we have to keep from repeating the 
same non-disagreements again and again. Nobody here, as far as I can 
tell, is suggesting that TCP be mandatory to support or use for a 
particular NSLP, only that it (or similar protocols, such as SCTP or 
DCCP) are appropriate parts of the tool kit.

You may also find it interesting to read some of the proposals that 
indicate how router alert options are being used. The two issues are 
orthogonal.

Maybe we need a FUD FAQ :-)

Henning