Subject: RE: [mobile-ip] Latency if QoS programming

From: "Glenn Morrow" <[email-masked]>
Date: Thu, 8 Mar 2001 11:38:00 -0600

I agree with Michael and we should make no mistake that if all of the
issues(requirements/assumptions) are the same, it will be a re-invention of
the wheel. 

Are people working with different requirements. An AS might be in order
before people spend their time on PDUs.

I believe this relates to the 3GPP question of:

I want a fairly inexpensive mobile to be able to communicate with QoS to a
host behind a T1 of a small corporate network. Bandwidth over the T1 is
signaled using RSVP. The mobile is using some "access specific" mechanisms.
Diff-serv is in the middle.  How will it work unless it is mandated that the
network can signal the mobile in an access specific way or the mobile itself
is mandated to interwork RSVP and the access specific protocol?

respectfully to you all,

Glenn

-----Original Message-----
From: Michael Thomas [mailto:[email-masked]]
Sent: Monday, March 05, 2001 10:43 AM
To: Hemant.Chaskar
Cc: [email-masked]; [email-masked]
Subject: [mobile-ip] Latency if QoS programming

Hemant,

I'd have a lot more sympathy for this argument if
what you'd proposed is, essentially, RESV with
router alert. As it stands, your proposal does
not address:

- multicast
- flow merging
- topology changes and localized healing
- cryptographic identity
- hopwise integrity
- policy based admission control
- flow aggregation
- admission based diffserv
- tunneling
- mpls-te 
- the mapping to various L2's

and probably a half a dozen other things
I can't remember off the top of my head.

In other words, in order to replace RSVP you are
going to have to reinvent RSVP. I frankly find no
motivation to do so, and in fact given recent
developments I think that RSVP may be salvageable
close to as-is and perform better than your
proposal.

		Mike

[email-masked] writes:
 > 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