Subject: [seamoby] QoS and Mobile IP

From: "Hemant Chaskar" <[email-masked]>
Date: Fri, 02 Mar 2001 17:39:58

>From: Michael Thomas <[email-masked]>

>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.

=> Despite a host of other reasons, if RSVP's OPWA has
performance inefficiencies in mobile environment, it cannot
be pushed to work with Mobile IP.

=> The solution of enclosing QoS Object in hop-by-hop
extension header, preferably with binding messages, performs
fast reservation on forward path. This will be important in
many unicast applications such as VoIP that cannot tolerate
interruption in quality, due to RSVP's round trip latency in
programming QoS on the new path, on every hanover.

=> Speaking of multicast. The question that comes to my mind is
whether it is necessary to send binding messages from MN if it
is receiving multicast traffic. If MN changes CoA, it can simply
use IGMP to register to multicast at that location. Conclusion:
Multicast and Unicast can be studied in different perspectives.

Also, state merging is an issue only when you use IntServ. In
DiffServ and MPLS cases there is no state to merge!

=> Overall, solution of including QoS object in hop-by-hop extension
header and performing forward reservations has its own merits. It
blends in well with mobility signals, works with micro-mobility
techniques and has performance edge over RSVP (at least in unicast
scenarios).

==>Hemant

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

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

---

From: Michael Thomas <[email-masked]>
Date: Fri, 2 Mar 2001 10:01:24 -0800 (PST)

> be pushed to work with Mobile IP.

   You're surely not saying that RSVP should never
   be used with MIP?

   And I generally object to always characterizing
   MIP and wireless by its least common denominator
   of cellular. 802.11 has, for all intents and
   purposes, the same characteristics as ethernet
   and RSVP, etc, work just fine there, thankyouverymuch.

 > 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. 

 > Multicast and Unicast can be studied in different perspectives.

   You can have shared reservations that do not
   involve multicast, you realize?

 > header and performing forward reservations has its own merits. 

   I find this claim rather dubious, but my main point
   is that I do not believe that anything this radical
   belongs in MIP WG. It should either be taken up in
   the (currently dormant) Network WG, or get enough
   support to do a BOF or something. 

	      Mike