Subject: RE: [seamoby] Hierarchical MIP, QoS, and Handoff

From: [email-masked]
Date: Thu, 1 Mar 2001 15:47:15 -0600

Yes, it goes end to end. But there is a basic difference illustrated 
by following example. If we look at the latency between time end nodes
are ready to use new CoA and the time QoS forwarding treatment is programmed

over the new path, it can be seen that RSVP takes one end-to-end round trip
time 
between these two events. On the other hand, including QoS object with
binding
messages performs QoS programming before the nodes release packets using
new CoA. This is shown by following illustration.

Suppose MN is currently at CoA1. Consider data traffic from the
CN towards the MN (downlink direction).

   o MN moves to CoA2.

   o MN sends BU from CoA2.

   ----[One way end-to-end delay]----

   o BU reaches CN. CN sends BA to MN at CoA2.

   In RSVP, CN sends PATH message to MN at CoA2.

   In our approach, QoS OBJECT OPTION for downlink packet stream(s)
   is included in HOP-by-HOP OPTIONS EXTENSION HEADER with the BA.

   o CN may start sending MN's packets to CoA2. These packets
   contain CoA2 as destination address. 

   **In RSVP approach, they are not identified by existing
   reservations for MN's sessions. This is because, RSVP session is
   primarily identified by destination address which now has changed
   from CoA1 to CoA2. Hence, these packets will get default
   forwarding treatment.**

   **In our approach, the packet carrying QoS information about these
   packets precedes these packets, and hence, they can get proper
   forwarding treatment.**

   ----[One way end-to-end delay]----

   o BA reaches MN at CoA2. In RSVP approach, PATH message reaches
   MN at CoA2.

   o In RSVP approach, MN sends RESV to CN.

   ----[One way end-to-end delay]----

   o In RSVP approach, RESV reaches CN. 

   **In RSVP approach, it is at this time that the proper QoS
   forwarding treatment is programmed at the intermediate network
   domains for packets destined to CoA2.**

Hemant

-----Original Message-----
From: Michael Thomas [mailto:[email-masked]]
Sent: 01. March 2001 13:33
To: Hemant Chaskar
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [seamoby] Hierarchical MIP, QoS, and Handoff

I don't see how this fundamentally changes
anything that James brought up. It still has to go
end to end, and it's still touching every router
in between MN and CN. 

What I do see is a lot of reinvention of RSVP
Rspec and Tspec's for no known reason.  The only
thing I can see of possible value is the ability
to piggyback the QoS update with the BU, but even
if this is the sole goal -- and that it's a worthy
goal which is not at all apparent to me -- I
imagine that there are better ways of doing this
with out reinventing RSVP: like, maybe,
piggybacking the BU on the PATH, or some such.

	     Mike

Hemant Chaskar writes:
 > Regarding the issue of round-trip latency in programming QoS forwarding 
 > treatment along new path after change in CoA:
 > 
 > This is intrinsic drawback of OPWA model of resource reservation of RSVP.
In 
 > the worst case, one round-trip time will include traversals of four
wireless 
 > links. This happens when both CN and MN are mobile.
 > 
 > Note that this drawback is eliminated in the approach to QoS signaling
based 
 > on including QoS Object in hop-by-hop options extension header along with

 > binding messages (draft-chaskar-mobileip-qos-00.txt). This draft was 
 > presented in SD and revised version (01) will be submitted soon.
 > 
 > Hemant
 > _________________________________________________________________
 > Get your FREE download of MSN Explorer at http://explorer.msn.com
 >

---

From: Michael Thomas <[email-masked]>
Date: Thu, 1 Mar 2001 14:19:13 -0800 (PST)

I really don't even know where to begin. It seems
that your claim is that RSVP's receiver oriented
PATH/RESV is either flawed, or should have a mode
which allows a single pass. I believe this leads
to overbooking for multicast since you don't get
to do flow merging properly and a host of other
reasons that I don't purport to understand well.

What I really don't understand is why MIP would be
the right place to solve this problem. If it has
merit, the RSVP folks seems like a much more
appropriate set of people to entertain such a
proposal. I suspect that they'd be able to supply
a lot more reasons why they designed RSVP the way
they did. Suggesting that mobileip is a breed
apart that requires its own QoS mechanisms sounds
just as wrong headed as RSVP folks designing their
own mobility protocol.

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 1 Mar 2001 14:19:13 -0800 (PST)

Mike