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

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

Hi Henning

My main argument is as follows.
If a feature is not needed you should be able to 
not use it!
If TCP is placed below NTLP, mandatory, you will have to support this feature
that you do not need!
Now the performance degradation that is imposed by using TCP
is related to:
* increased packet length (there are still open issues 
   related to header compression
   of the SACK and TCP time stamp options);
* TCP is using a three-way handshake mechanism to establish a connection, 

Regarding setup delay, the above two issues cause a performance degradation, in 
links that do not need to use these features.

Best Regards,
Georgios

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: woensdag 19 februari 2003 15:48
To: Georgios Karagiannis (ELN)
Cc: 'Tschofenig Hannes'; [email-masked]
Subject: Re: AW: [NSIS] Transport functionality in the NTLP

> What do you mean?
> In wireless networks link layers provide such features!!!!!
> 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).

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

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.

> Best Regards,
> Georgios
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Ping Pan <[email-masked]>
Date: Wed, 19 Feb 2003 11:00:19 -0800

Geoegios and Henning,

I have a feeling that there is a misunderstanding here.

Argument 1: if we have so many issues in the existing RSVP transport, 
and BGP/LDP are two operational protocols running over TCP between 
routers, then why not run RSVP payload over TCP between routers? (The 
overhead for a TCP socket is very small, at least in the latest FreeBSD 
and Linux.) This is a valid point.

Argument 2: reliable message transport is a good thing, but it can be 
accomplished at different layers. In case of radio access network, there 
is a underlying reliable transport layer, and the wireless bandwidth is 
very expensive, so running RSVP raw-mode is just fine. Why TCP at all? 
This is also valid.

After talking to Georgios during the interim meeting, I had made an 
effort to emphasis the importance of swapping transport layer protocols 
during my presentation.

I suggest the following: in case of transporting RSVP payload (call it 
NTLP, if you wish), we could have three different methods:

1. RSVP raw-mode: as defined in the RFC, we can just run it over the 
reliable wireless access link.

2. RSVP-over-UDP: see the RFC.

3. RSVP-over-TCP:

One TCP session is established between RSVP neighbors. (Check RSVP-TE to 
see how to discover and create RSVP neighbors.) For all RSVP messages, 
just send them through the TCP socket. Unless you want to support RSVP 
soft-state time-out, there would be no need to send refresh messages at 
all. I argue that we will save more link bandwidth, process less 
messages, and have less bugs to discover.

There is one problem wrt the Path messages, since they are delivered e2e 
and use IP router alert option. Well... RSVP Path messages can be 
delivered hop-by-hop based on the destination address in the session 
object. There is no need to have this IP Router Alert option hack in the 
first place.

In any regard, I think this would be work.

If you want to feel secure, run your SCTP between routers. I have 
thought TCP/MD5 (free code BTW) would solve a lot of problems already.

2 cents,

- Ping

---

From: Michael Thomas <[email-masked]>
Date: Thu, 20 Feb 2003 10:05:49 -0800 (PST)

> messages, and have less bugs to discover.

Uh, how else would you reap dead
routes/reservations?  Which is really to say that
the underlying transport is not exactly suited to
the actual transport requirements, therefore those
requirements must be hacked in at the appliation
layer. This is why I think that Henning's "use a
real transport layer" is a gloss and deserves a
detailed look at *all* of the transport
requirements. I suspect that in the end, a lot of
this is six of one, half dozen of the other and
that living with the devil you know (RSVP's
transport) is at least proven to work, and that we
don't want to be lured into the best being the
enemy of the good.

 > object. There is no need to have this IP Router Alert option hack in the 

This presupposes that there a 1:1 mapping of
access to next hop and signaling. Router alert
makes that requirement explicit. Something else
would need to make the same requirement. It also
possibly opens a can of worms of not making that a
requirement.

		Mike

---

From: Ping Pan <[email-masked]>
Date: Thu, 20 Feb 2003 10:31:12 -0800

Michael Thomas wrote:
> routes/reservations?  

Easy. If the TCP session is gone, withdraw all associated stuff. LDP and 
BGP are working this way. Again, if explicit withdraw is too tough to 
deal with (not sure why), send periodic refresh as what has been defined 
in RSVP and RFC2961.

- Ping

> Which is really to say that