Subject: RE: [Seamoby] Examples of CAR discovery

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 2 Apr 2002 17:43:23 +0200

Charlie,

Just catching up with the Easter email!

  > I'd like to suggest that we allow handovers based on availability
  > of resources for less than 100ms.  The handover can be accomplished
  > in a lot shorter than that amount of time, and the CAR discovery is
  > exactly for the purposes of doing a handover.  Why disallow the more
  > dynamic behavior?

=> Do you have some proof that this assertion will
hold in all cases? I mean the 100 ms time limit. 
I'm curious because I haven't seen anything published
on that and I'd like to know under what assumptions
this statement would hold. 

Hesham

  > 
  > > There is another issue here. Suppose we consider a dynamic QoS
  > > measurement on the order of 200 ms and a total (L2 + L3) 
  > handover time
  > > of 40 ms as in previous email. Now, just for the sake of argument,
  > > suppose we consider that the QoS measurement delivers 20 
  > bytes of data,
  > > minus IPv6 headers which are removed by header 
  > compression. This should
  > > be enough for the IPv6 address of the access router and a 
  > 4 byte QoS
  > > level. By my calculation, that is approximately 8kbps 
  > just to deliver
  > > QoS measurement data to the mobile node. That's a lot of 
  > bandwidth. In
  > > fact, it is more bandwidth than is used to deliver 
  > cellular voice in
  > > current 3G systems.
  > 
  > Are you worried about delivering _any_ data to the mobile node?
  > What was special about QoS data here?  If we had 20 bytes of data
  > to be delivered to the mobile node, that wouldn't take very long
  > compared to the handover time.  Do you suggest that this be 
  > delivered
  > periodically?  I would not like that!  Otherwise, I don't see how
  > the 8kbps figure was arrived at...
  > 
  > >> I would think that CARD would "naturally" be constrained 
  > to consider
  > >> dynamic behavior with time constants not less than, say, 30 ms.
  > > 
  > > I see the time constant as rather higher, more like seconds.
  > 
  > Are you saying that a quantity being measured has to be stable for
  > seconds, before a mobile node can act on the measurement?
  > 
  > This is not right, I'm pretty sure.  Consider the following:
  > 
  > - CAR agrees to provide video QoS to a mobile node.  CAR even
  >   reserves the capacity for 100ms, waiting for the node to arrive.
  > 
  > - Another customer shows up 120ms later (we have lots of 
  > customers :-)
  >   and uses up that video bandwidth
  > 
  > By your definition, the mobile node should not even consider CAR,
  > because CAR is unwilling to tie up its resources for more than 100ms
  > just on the _prospect_ of a handover.  By my understanding, it would
  > be better (for smoother handovers) for the CAR to reserve 
  > the bandwidth,
  > but it would be uneconomical to do so for "seconds".
  > 
  > > I think one needs to distinguish between InterTHO and IntraTHO. I
  > > believe the time constants can be considerably different, 
  > and the need
  > > for involvement of the mobile, it's user, or potentially 
  > software agents
  > > acting on behalf of the user, are considerably different. 
  > For InterTHO,
  > > the time constant can be up to seconds, for IntraTHO it 
  > is 10's of ms.
  > 
  > The time constant _could_ be large, but even for InterTHO it does
  > not have to be -- the two interfaces could (and often would) be on
  > the same router.  I would hope that we don't have to deal 
  > with mobile
  > agents here.
  > 
  > Besides that, IP-layer stuff should not depend on the specifics
  > of the technology (i.e., the 'T').  It should work over whatever
  > reasonable technology is going to support handovers.  Maybe not
  > carrier pigeons.
  > 
  > >> Regarding (3), note that a local optimization for time and
  > >> smoothness is "typically" not good for wide-area optimization
  > >> of network paths.  Chained tunnels provide a good illustration
  > >> about why this is the case.  It would be even worse for extended
  > >> patch-ups to QoS.
  > > 
  > > I'm not sure I understand your point. I agree about 
  > chained tunnels, but
  > > I don't see how this applies to QoS.
  > 
  > Nothing deep here...  If I get QoS at the router, by appending a
  > QoS-reserved path between access routers to a QoS-reserved path
  > ending at the previous access router, I get QoS, but it takes more
  > network resources than would otherwise be necessary.
  > 
  > >> Another way of saying this, is that although CARD is separable
  > >> from smooth handover, it has to be considered in light of what
  > >> is likely to happen once the discovery takes place.  And, I
  > >> would also say that we should be allowed to discover whatever
  > >> information by way of (1) that would be use during process (2).
  > > 
  > > Again, I think the distinction between InterTHO and IntraTHO is
  > > important.
  > 
  > I don't think we should design CAR discovery around such a
  > distinction.  Of course, it's important for any reasonable
  > system design, but that does not have to affect the discovery
  > protocol by which CARs are identified.
  > 
  > Regards,
  > Charlie P.
  > 
  > _______________________________________________
  > Seamoby mailing list
  > [email-masked]
  > https://www1.ietf.org/mailman/listinfo/seamoby
  > 

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 02 Apr 2002 07:51:02 -0800

Hello Hesham,

> this statement would hold.

Of course it does not hold in all cases.  But it does
hold in some cases of interest (e.g., 802.11), and we ought
to be making the protocol work for those cases.

I don't know what kind of assumptions you would want
to hear.  One easy assumption is, "the handover can
occur in under 100ms" -- but somehow I expect you
were asking for more...

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 02 Apr 2002 07:51:02 -0800

Hello Hesham,

Regards,
Charlie P.