Subject: RE: AW: [NSIS] Transport functionality in the NTLP

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Wed, 19 Feb 2003 15:03:31 +0100

Hi Hannes

> There are scenarios, for example:
> * wireless access scenarios will only need
> a part of these features, since these features can be 
> provided by other 
> means

>> i sometimes have the impression that this is more like 
>> a feeling than based on solid grounds.

What do you mean?
In wireless networks link layers provide such features!!!!!
Please, do not impose performance degradations when it is not needed!!!

> * the wired part of a cellular system that does not need these features.
> regarding end to end addressing, use the same addressing 
> procedures as RSVP,
> since they are working fine!

[hannes] if i got john's comments at the nsis interim meeting 
[hannes] correctly then we do not try to create a protocol which 
[hannes] is tailored to a very specific application, environment or scenario. 

[hannes] creating a "more lighweight" (whatever that means) protocol for very
[hannes] specific applications, environments and scenarios with the drawback that the
[hannes] entire protocol becomes a mess is probably not the right choice (an example:
[hannes] providing congestion control at the nslp in an end-to-end fashion).

Wireless scenarios are not specific applications!!!!
Actually the goal of starting NSIS was to solve QoS issues in 
wireless scenarios. Please do not forget this!!!!
Other types of scenarios could also use NSIS, but in my opinion 
NSIS should at least satisfy the requirements imposed by 
wireless scenarios!!!

Best Regards,
Georgios

> 
> Best Regards,
> Georgios
> 
> 
> -----Original Message-----
> From: Tschofenig Hannes [mailto:[email-masked]]
> Sent: woensdag 19 februari 2003 11:57
> To: Lars Westberg (EAB); Geib, Ruediger
> Cc: [email-masked]; [email-masked]
> Subject: RE: AW: [NSIS] Transport functionality in the NTLP
> 
> 
> hi all, 
> 
> if we want to support 
> a) applications which demand limited transport layer 
> functionality and 
> b) other applications which demand more transport layer functionality 
> then we need to use peer-to-peer addressing for signaling 
> message delivery
> (instead of end-to-end addressing). peer-to-peer addressing 
> places the least
> restrictions on the ability to support different protocols 
> executed between
> neighboring peers. 
> 
> does this sound reasonable? 
> 
> ciao
> hannes
> 
> > -----Original Message-----
> > From: Lars.Westberg [mailto:[email-masked]]
> > Sent: Wednesday, February 19, 2003 11:28 AM
> > To: Geib, Ruediger
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: AW: [NSIS] Transport functionality in the NTLP
> > 
> > 
> > 
> > The transport protocol may have these function, but I do not 
> > see that it is neccessary in all applications. Un-reliable 
> > transport is a must in this protocol.
> > Make the NTLP as a minimum set of functions.
> > 
> > Regards Lasse
> > 
> > "Geib, Ruediger" wrote:
> > 
> > > Dear all,
> > >
> > > the transport protocol must ensure that signaling messages 
> > aren't lost or corrupted. Further, NTLP is expected to deal 
> > with route changes. I don't think that an unreliable 
> > transport is best possible solution supporting this task. 
> > Congestion avoidance is a benefit to users and operators, 
> > that's why it must be present too. To me, a) seems to be 
> > reasonable option.
> > >
> > > Regards, Rüdiger
> > >
> > > | a) yes the protocol must always guarantee this feature 
> explicitly
> > >
> > > | 1. Congestion control (NTLP must protect the local network
> > > | from signalling overload) - suggest (a)
> > > | 2. High probability of delivery to the next NE even in the
> > > | face of packet drops - I suggest (a)
> > > | 3. Guaranteed delivery to next NSLP node with feedback on
> > > | success - I suggest (d)
> > > | 4. Bundling of small messages - I suggest (c), doing it has
> > > | only local significance
> > > | 5. Segmentation to avoid link/path MTU limits - I suggest
> > > | (a), or (b) if you know all your links up to the next NE can
> > > | be engineered to have a big enough MTU
> > > | 6. In order delivery and duplicate detection/removal - I
> > > | suggest (a) (maybe (c), if you are prepared to put it back
> > > | locally in adjacent hops)
> > > | 7. Framing (supporting message boundaries) - I suggest (a)
> > > | 8. Flow control - not sure about this one. Maybe (c)
> > > | 9. Security (confidentiality, integrity protection) - I
> > > | suggest (a) or (b)
> > > _______________________________________________
> > > nsis mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/nsis
> > 
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> > 
> _______________________________________________
> 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: Henning Schulzrinne <[email-masked]>
Date: Wed, 19 Feb 2003 09:48:22 -0500

> Please, do not impose performance degradations when it is not needed!!!

Since this is an engineering working group, maybe we can agree that 
anybody who claims that "X causes a performance degradation" should at 
least be kind enough to cite some verifiable evidence, not just hearsay, 
and then also show that the replacement mechanism is free of those defects.

As was pointed out during the interim meeting, nobody has proposed 
mechanisms at the NSLP layer or (above-L4-transport) NTLP layer that 
differ fundamentally from what we have at TCP or SCTP layer. It eludes 
my understanding why the same mechanism implemented at higher layers 
should be more efficient than implemented at lower layers.

As was also discussed repeatedly, RFC 2961 shows what happens if you try 
to do this at the "NSLP" layer: you get a mess and a transport mechanism 
that reflects transport knowledge ca. 1975.

If there is no congestion or loss, TCP (or SCTP) are essentially free, 
except for the ACK (which you'll need in any event).

> NSIS should at least satisfy the requirements imposed by 

You have unfortunately not made an engineering case, besides adding !!!, 
that implementing reliability or other functionality below NTLP harms 
wireless deployability. The debate would be furthered and be less 
circular if you could do so by arguments other than assertions.

Things like TCP header compression are available for wireless links; if 
you replicate this at higher layers, you don't get the benefit of any of 
those developments.

That said, the design choice I presented explicitly allowed for 
hop-by-hop unreliable forwarding, with only end-to-end reliability. Once 
you actually measure the performance in high-loss links, you won't like 
it, but it doesn't add substantial cost to the design.

---

From: "Jim Fleming" <[email-masked]>
Date: Wed, 19 Feb 2003 09:44:53 -0600

"cite some verifiable evidence, not just hearsay" ?

====

Have people considered working code ?

Jim Fleming

http://IPv8.isfun.net