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

From: "Hemant Chaskar" <[email-masked]>
Date: Sat, 04 Aug 2001 01:23:35

Hi Samita:

Please see some answers inline:

>From: Samita Chakrabarti <[email-masked]>
>Reply-To: [email-masked]
>To: [email-masked], [email-masked]
>Subject: [mobile-ip] Comments on 
>draft-ietf-mobileip-qos-requirements-00.txt
>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 ?

[Hemant] It was argued on the MIP QoS the mailing list that it is not 
sufficient just to quote requirements, but provide some insight into what is 
missing from the current QoS mechanisms. The idea was this would help the 
relevant working groups to focus on the precise missing piece and work out 
the solution. RSVP (intserv or intserv+diffserv(RFC 2998)) is one such QoS 
mechanism that exists as an RFC. That is why the mention of RSVP.

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

[Hemant] We can put DiffServ in there as well and also quote the point that 
you are mentioning about dynamic service level agreements. Anyway, that work 
has already started in Seamoby in the form of moving diffserv context in the 
context transfer protocol.

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

[Hemant] There was a concern raised on the language that you are proposing. 
Somebody said that such a language implies that new end-to-end QoS must be 
established. The message that we are sending is that "handovers may change 
end-to-end path", so solution may not only focus only on the local path 
changes. Now  if the QoS mechanism cares about end-to-end path it will have 
to be reinitiated, if not it may ignore the end-to-end change.

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

[Hemant] This is a general requirement for QoS, even for fixed hosts. Could 
you please explain why it is relevant "only for mobile IP." This draft does 
not want to address requirements that are "common" to both fixed and mobile 
hosts, rather we should focus on requirements that are "exclusively" for 
mobile IP.

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

[Hemant] The question we should ask is whether inter-technology handover 
apparent at IP layer. Also what is the requirement as such? I think such a 
handover is transparent to IP layer, but I can put that requirement (what is 
it first?) in if WG agrees on it.
>
>
>5. The obvious requirement section is not too obvious to many. Can we 
>clarify?

[Hemant] Could you please be more specific and point out which item there is 
not obvious and what the confusion might be.

>Thanks!
>-Samita

Thanks for your comments.

Hemant

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

---

From: Samita Chakrabarti <[email-masked]>
Date: Mon, 6 Aug 2001 17:06:07 -0700 (PDT)

Hi Hemant,

Thanks for your reply. Some comments below. 

> context transfer protocol.

Ok.

> to be reinitiated, if not it may ignore the end-to-end change.

I see,  "should be"  may be restrictive. I understood  after I read
your explanation. Do you think, if you put your explanation there, it might
avoid any future confusion ?

> hosts, rather we should focus on requirements that are "exclusively" for 

Yes, it might be a general issue in IPqos area. But, mobileip will be most
affected in large scale deployment. Having a direction, would have helped.

> it first?) in if WG agrees on it.

Offhand I can see bandwidth capacity ( say between 3G and wireless LAN)
variation between two netwroks and also the latency in two different
technology. The qos application may be aware of these during inter-technology
handover. It may not affect the IP layer and if so, then perhaps we may want
to mention that or leave it open ?(WG may help us on that decision, as you
suggested).

> not obvious and what the confusion might be.

The draft has a section on obvious requirement where it states that
qos solution for Mobile IP should satisfy obvious requirements 
such as scalability, security, conservation of bandwitdth....etc.

It's not clear to me whether the above listed requirements are
a must requirement. I understand it's quite difficult to 
quantify them as the answers may be unknown at this point.
I'd say, it would be good to list a minimum set of items to
consider in the Qos solution as obvious (basic?) requirements.
(the language "such as" appears to be for examples only)

-Samita