Subject: [seamoby] Latency if QoS programming

From: [email-masked]
Date: Mon, 5 Mar 2001 09:57:06 -0600

Some packets may overtake the packet carrying QoS information packet. But
let us look at the following math. Assume that T is forwarding delay (not
counting processing time required) for a hop. Let P be the processing time
of PATH or RESV or QoS Object hop-by-hop option at a network node.

Assume 3 hops in the end-to-end path that are concerned with programming QoS
forwarding treatment. Let us look at the packet stream from CN to MN and let
us count the number of packets at each of these nodes that would get default
forwarding treatment due to lack of QoS forwarding information. Let us take
the time difference between the potential arrival of first packet at a
network node and the time QoS forwarding treatment is programmed at that
node as an indication of number of packets that would get default forwarding
treatment at that node. 

Let us indicate the node closest to CN by Node 1. I.e. I am assuming the
following scenario CN--->Node 1---->Node 2---->Node 3--->MN. I am also
assuming that PATH packet/QoS Object hop-by-hop option packet and first data
packet arrive at Node 1 one after another.

               RSVP                           QoS object hop-by-hop option

Node 1    3T+3P (for PATH) + 3T+3P (RESV)           P

Node 2    3T+3P (for PATH) + 2T+2P (RESV)           T+2P

Node 3    3T+3P (for PATH) + T+P  (RESV)            2T+3P

It can be seen that the latencies in second column (and hence number of
packets getting default treatment) are much smaller that those the first
one.

Hemant Chaskar
Nokia

-----Original Message-----
From: ext Michael Thomas [mailto:[email-masked]]
Sent: 05. March 2001 10:13
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [seamoby] QoS and Mobile IP

[email-masked] writes:
 >  > => The solution of enclosing QoS Object in hop-by-hop
 >  > extension header, preferably with binding messages, performs
 >  > fast reservation on forward path. 
 > 
 >    No it doesn't. If it needs to go clear back to the
 >    correspondent node to change filter specs, you're
 >    already too slow in the degeneate case. 
 > 
 > -----> No, you don't get the point still. You have to 
 > -----> realize that packet carrying QoS object PRECEDES any 
 > -----> data packets using new CoA. Please read the illustration that
 > -----> I gave in previous email again. Hence, QoS forwarding will
 > -----> be in place when these new CoA packets hit the intermediate
 > -----> routers. RSVP takes one round trip time for that. 

  What makes you think that other packets will not
  overtake the qos establishment packet? FIB based
  forwarding is a whole lot faster than installing
  a reservation.

	Mike