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

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

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

---

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

Mike