Subject: [seamoby] Latency in QoS programming

From: [email-masked]
Date: Mon, 5 Mar 2001 11:17:53 -0600

-----Original Message-----
From: ext Michael Thomas [mailto:[email-masked]]
Sent: 05. March 2001 11:43
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: 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.

==> Mike, 

==> No concept of router alert in IPv6

As it stands, your proposal does
not address:

- multicast

==> I replied in the earlier email that you do not need binding messages
with multicast. Clearly, this is not Mobile IP issue. Anything that does not
have binding messages in it is not Mobile IP issue.

- flow merging

==> No multicast issue, so no flow merging issue to be studied in Mobile IP.

- topology changes and localized healing

==> This is an interesting point. I will study this further. I have no
answer to it at this time.

- cryptographic identity

==> This is irrelevant. Let us stick to point.

- hopwise integrity

==> Irrelevant. Let us stick to point.

- policy based admission control

==> Irrelevant. This is implementation issue. IETF never addresses it. QoS
object has enough information in it for policy based admission control.

- flow aggregation

==> Irrelevant. I am not doing network traffic engineering with this scheme.
Go to MPLS WG to study this. It is router-router issue. Not stream-router
issue.

- admission based diffserv

==> Again, implementation issue. QoS object has sufficient information to
implement this. Creating interdomain SLAs is not done on a per stream basis.
When the stream arrives at DiffServ edge, edge router has to decide whether
it lies within SLA (this is nothing but what you call policy). Our QoS
object has sufficient information to implement this. QoS object will not do
SLA, it will provide information about packet stream to the module that
checks that SLA is not violated.

- tunneling

==> I don't understand this point.

- mpls-te 

==> Go to MPLS WG. It is router-router issue and not stream-router issue.
Using MPLS TE (scope of MPLS WG) edge router would know how much traffic
destined to particular egress and at what QoS it can admit over that LSP.
When packet carrying QoS object hits this edge router, that router uses
information in QoS object option to decide whether it can admit this packet
stream on that LSP.

- the mapping to various L2's

==> Irrelevant for this draft. Go to ISSLL and ask them to enlarge their
scope to include this solution.

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

==> They are probably as irrelevant as some of the above issues.

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.

==> I strongly suggest that we stick to the point and remain within the
scope of Mobile IP. We should not create confusion by bringing in irrelevant
issues just to push RSVP further. This way, we cannot arrive at a good
protocol to meet our performance needs.

==> Further, I don't need any sympathies as I am not zealous about one
protocol or the other. What I care about is technical merit and performance
of protocol! Also, you should look into bigger picture of IP QoS and
differentiate various issues in different scopes. End-to-end QoS cannot be
studied in one WG, neither can be done using one protocol. What we need is
protocol that integrates with different QoS modules that might exist in the
end-to-end path.

==> Hemant

		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