Subject: (ION) Hit ratio in NHS...

From: Navin Agrawal <[email-masked]>
Date: Tue, 13 Jan 1998 00:38:43 +0000 (GMT)

Hello all,

	I have a doubt regarding NHS. I know it is off the line, but still
its answer will help a lot. So I request all experts to give some comments
on it.
	First, I will quickly discuss how NHS is utilized?? then will
come to the point. Now here I go...
	When a host wants to setup a direct communication with a
destination host which is not in the same host, it sends a NHRP query to
the NHS of its LIS(assuming the mapping is not available in its own
cache). If the NHS is not having the mapping the source host is looking
for, it will forward the query to other NHS towards destination host.
After some ... the source host will get the mapping and also the NHS of
its  LIS will update its cache with this mapping. Now next time if the
same kind of mapping is required for the same destination host but on
some other source host, because the NHS is having the mapping, this query
will be solved very fastly. I will call this situation as a HIT in the
cache table of the NHS.
	Now if I say that the hit ratio will depend on the kind of traffic
say Interner backbone traffic or Corporate backbone Traffic or Campus
Backbone traffic etc., then How far I am correct??
	Assuming that I my argument is true, I speculate that only for
corpaorate backbone traffic , the hit ratio will be a good number for
others it will not. Again, I request you to tell me, how far I am correct.
		
	If somebody thinks, this is a very timid kind of question,pls
forgive me for trouble.

regards
-Navin

X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.

---

From: Reinaldo Penno Filho <[email-masked]>
Date: Mon, 12 Jan 1998 18:53:44 -0200 (EDT)

HI,

I have a little doubt here. It is said

------
If the NHRP Resolution Request is triggered by a data packet then S
   may, while awaiting an NHRP Resolution Reply, choose to dispose of
   the data packet in one of the following ways:

     (a)  Drop the packet
     (b)  Retain the packet until the NHRP Resolution Reply arrives
          and a more optimal path is available
     (c)  Forward the packet along the routed path toward D

   The choice of which of the above to perform is a local policy matter,
   though option (c) is the recommended default, since it may allow data
   to flow to the destination while the NBMA address is being resolved.

----

Just like in lane 1.0 maybe we should have a procedure to make sure that
all packet sent through the routed path have arrived, ie, there is no
packets in-flight.

Since the SVC path is faster than the routed path, maybe some packets will
arrive out of order and if there is a problem with buffer space this will
cause retransmissions, since the destination will not be able to put the
datagram together.

I´m not sure this will happen. It´s just an ideia. Maybe I got everything
wrong...

Reinaldo

---------------------------------------------

Brazilian Research Network
http://www.rnp.br
[email-masked]

---------------------------------------------

---

From: Joel Halpern <[email-masked]>
Date: Mon, 12 Jan 1998 22:30:27 -0500 (EST)

The LANE 1.0 Flush mechanism is specifically for those protocols that can
not tolerate disorder.  MostLANE implementations will either never flush
or avoid flushing for IP (and similar) services.  The flush mechanisms are
a kludge wit necessary but excessive mechanisms and timeouts.
There is no reason to put that into NHRP.

Yours,
Joel M. Halpern                         [email-masked]
Newbridge Networks Inc.

---

From: Diane Schuster <[email-masked]>
Date: Wed, 14 Jan 1998 06:55:44 -0500

Reinaldo,

> cause retransmissions, since the destination will not be able to put the

LANE was emulating a bridged environment. Normal bridges deliver all
packets in the order in which they were sent because only one path is
used from the source to the destination.

NHRP is a routed environment. Each packet in a routed environment is
routed on a hop by hop basis. There is always a chance that packets will
arrive out of order because a single routing decision at a single router
could cause the packet to take a faster or slower path than the last
packet took. If it matters to the application, then an appropriate
transport layer should be used (e.g. TCP) to ensure that all packets
arrive at the destination application and that they are delivered in
order. So the arrival of packets out of order because of a change from
the routed path through the NBMA to a shortcut path is nothing unusual
in a routed environment.

-- 
Schuster Consulting	
[email-masked]
(919) 831-9019

---

From: Navin Agrawal <[email-masked]>
Date: Thu, 15 Jan 1998 17:13:10 +0000 (GMT)

> > I´m not sure this will happen. It´s just an ideia. Maybe I got everything

	While the process of ATM short-cut link getting constructed is
going on, we have to follow either of the three options mentioned above
and the recommended one is option (c).

	As Reinaldo mentioned this causes disorder delivery of packets.
This is OK if the upper trnsport layer is UDP. But If it is TCP, then
there will be retransmission of all those packet, causing drop in the
overall throughput. So why not let the above decision of farwarding/not
forwarding be left on the type of protocol??

	* Like forward the packets if the protocol type is UDP, otherwise
goto next step.
	
	* forward the IP packets(of TCP types) only if it seems that the
session is not going to last long. Because even there happens to be
retransmission of packets, as the no of packets is less, effect on the
throughput will be less.

	Pls. tell me, If have made some wrong argument.

Regards
-Navin

---

From: Albert Manfredi <[email-masked]>
Date: Thu, 15 Jan 1998 14:15:45 -0500

Navin Agrawal wrote:

[ ... ]

> retransmission of packets, as the no of packets is less, effect on the

The point is, though, that you can't completely ignore function for
the sake of raw speed. UDP over routed-then-short-cut path might be
great in that it doesn't cause re-requests from the Transport Layer,
but it's only great because UDP itself is insensitive to messed up
packet sequencing. The application layer might not be. It might have
to throw all the out of sequence UDP frames anyway. (Example: video
would likely be sent over UDP, but no way can video packets be
processed and displayed if they are out of sequence.)

I could easily argue that TCP makes a lot more sense than UDP to
send over short-cut paths _because_ TCP can compensate for out of
order frames during the transition to the short-cut path.

Also, FTP, which uses TCP/IP, is one of the applications that could
make very good use of short-cut paths.

I think the best answer is to decide how many data frames you want
to allow to flow along the routed path at all. That's a perfectly
good knob to use to fine-tune NHRP and MPOA to your specific
application. It's easy enough to give examples and counter examples
of different strategies that make sense in different situations. One
answer just won't cover all cases, in my opinion.

Bert
[email-masked]
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.