Subject: [mobile-ip] Comments on draft-ietf-mobileip-qos-requirements-00.txt

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 3 Aug 2001 16:52:31 -0700 (PDT)

Hello Hemant:

I am reading the mobileip-qos requirement draft again, and I think it
is still missing some clarification and some of my comments on mip-qos
alias were not addressed. Let me explain them here again, and why I think
they should be in the requirement document.

1. I assume the goal of the requirement document is not to provide or point
   to  any particular qos solution for mobile-ip. Yet, at number of cases, in
   the document we have references and examples of RSVP qos mechanism. Is it
   because we do not have any experience or data available for other Qos
   mechanism(such as diffserv) for mobile ip ? Or is it trying to point out
   some of the drawbacks of RSVP in mobileip environment ?
   
   If we discuss problems or merits of qos mechanism, we should  discuss
   that for different mechanisms. May be the examples belong to appendix.
   For example, diffserv seems more appropriate to me in mobileip case, but
   then it may need to have some dynamic service level agreements between
   the nodes where the handover is taking place.

2. section 3.1, bullet item 2, it states:
    "Of course, if
   the end-to-end path changes at large after handover, the QoS
   mechanism MUST be able to address that in a manner that is
   consistent with the QoS scheme(s) used along the new
   end-to-end packet path."
   
   By "new end-to-end" path it means the path between two communicating nodes.
   Should not it say that Qos mechanism should be established in the 'changed
   or new end-to-end' path depending on the Qos mechanism ?

3. The scalabality is a mobileip specific qos issue that this requirement
   draft needs to clarify. As JC Martin and I requested the following item in
   our earlier comments to mip-qos alias:
   
   A salability requirement could be that no per MN state should be kept
   in the inner nodes: state should be contained as close as possible to the
    MN. Also : if the QoS Mechanism is using signaling, it should be aggregated
    as close as possible to the MN.

4. 
   How about adding a section here for 'inter-technology 
   handoff'. What's our qos requirement there?
   Do we expect it to be transparent as it's happening in IP layer ?  

5. The obvious requirement section is not too obvious to many. Can we clarify?

Thanks!
-Samita

---

From: Michael Thomas <[email-masked]>
Date: Sun, 5 Aug 2001 05:42:11 -0700 (PDT)

In general, it would be better to steer clear of 
"better" or "worse" wrt wireless (as if that were
a monolithic thing anyway). RSVP as a general
qos signaling mechanism is what we have now, and
it seems quite reasonable to point out things
which are not going to work well. The same thing
obviously needs to be done with diffserv too, but
you wouldn't expect nearly as many issues since
it's mainly a L2/L3 queuing problem which can be
safely brushed aside :-)

	       Mike