RE: [MIP-QOS] RE: MIP-QOS MIP QoS Mailing List is Active Now

Hello,

Here are some comments on the requirements :

2> I believe this can be accomplished with micro mobility protocols which hide the mobility to the home network. About the delay to establish the new QoS path, my feeling is that it can be done before the IP handoff by some sort of predictive reservation scheme (which would be relatively easy to set up in a micro mobility domain). The problem here lies when the mobile moves between two micro mobility domains. The QOS path may take more time to be set up but once again some predictive path could be determined in advance.

Using micro mobility has many advantages one of which is that the qos path is not changed in the core (which can then easily use Diffserv since the path is not highly dynamic) when you move within a domain. In the domain itself, it seems feasible to maintain more states and therefore deal with a higher handoff rate.
[Morrow, Glenn ]

Most of what you say is true and I suspect will likely be supported by the end solution. Your comments are in line with requirement #4. I was thinking of the macro problem between administrative domains where the signaling goes as far as it needs to go at the macro level and across administrative domains. I believe that at least bandwidth used must be accounted for on handoff even in the wireline case between a small enterprise with 802.11 (perhaps T1 access into the premises) and a cellular infrastructure that would have the characteristics you describe. The point is that your comment is pointing to the solution space of requirement 4 with a large cellular core infrastructure in mind.

4> Micro mobility also answers the scalibility problem. Maybe the micro mobility domain can be handled with a Diffserv mechanism but i believe the cells themselves should maintain more states. This comes to the conclusion that you can use Diffserv on the wired part of the network (micro mobility + core) but probably not on the wireless link.
[Morrow, Glenn ] I think we are saying the same thing with different terminology. I tried to write the requirement without referencing the specific semantics of a solution.

6> I don't understand this. Using the mobile's home address is not fine ?
[Morrow, Glenn ] Hmmm - again think macro when the COA changes and how RSVP indexes it's state tables and how security indexes SAs and the extent to which handoff can occur between access technologies at both the micro and macro levels served via separate autonomous systems of cellular and enterprise.

7> More protection could be provided if the medium has a a high error rate. In IEEE 802.11, many transmission rates (with a more or less robust code -- high rate is less robust of course) are used according to the link's quality. Is this what is meant in this requirement ? What media should be considered ?
[Morrow, Glenn ] In cellular, as the voice codes go over the air, portions of the code words that are "more important" than other portions of the code word are actually duplicated and FEC'ed (forward error correction mechanisms applied) before they are transmitted over the air. This duplication and FECing of these "very important" parts of the code words is commonly referred to as unequal protection. If unequal protection was not used, your cellular calls would sound like dog-poop and the cellular operators would likely not be able to charge as much and an operator who did turn this on would likely get more customers and more revenues than an operator who didn't.

One of the excuses of having to have a layer 5 entity (ex. SIP) intimately associated via signaling with the routing equipment on the visited network is this need to have the cellular access equipment perform unequal protection on the voice codes as they are sent over the air. If you ever want to get rid of this coupling for cellular networks, then your reservation/binding scheme will have to convey the codec used and the routing equipment will have to be put into the loop of this signaling. Another solution people have proposed is to sniff the packets all the time - this isn't very good. In order to do unequal protection you must know the format of the code words i.e. the codec being used. Knowing a traffic class or the delay or the bandwidth won't work. There are many codecs and sometimes the codec actually consists of multiple codecs. I hope this answers your question.

When we get into the non-mip contengent of the IETF, this will definitely come up and a layer 5 solution may end up competing due to this requirement. I'd rather people get these issues out on the table and be upfront about this earlly on.

8> Is two way really an issue ? Maybe for the ACKs ? RSVP deals with duplex links as 2 simplex links.
[Morrow, Glenn ]

It is an issue in that sometimes it is desirable to reduce setup delay and bandwidth used over air for signaling when the optimization can occur. From my understanding of NSIS, the solution may or may not be based on RSVP. If RSVP can meet the requirement then it can meet the requirement.

9> Same comment as 8>
[Morrow, Glenn ] Agreed. I'll bet we can fit both into one.

14> I believe this depends on whether we talk about IPv4 or IPv6. It seems to me that the solution is not the same in both cases. When talking about IPV4/IPV6 being dealt with seperately, i think the principles should be the same (esp. if route optimization is a requirement). However, IPv6 has some specific functionnalities which we should take advantage of.
[Morrow, Glenn ]

There are actually some security issues with the current MIPv6 spec pertaining to this functionality as well. I know this is a shocking thought but whatever NSIS turns out to be may superseed even MIP. This is because NSIS is dealing with all of the requirements from the get go. I can actually think of a signaling methods for IPv4 that would allow application packet delivery, the initiation of a binding and a reservation. The question is how far does NSIS want to go. Also see my question below about same solutions for both layer 3 technologies.

Gwendal LE GRAND
[Morrow, Glenn ]

Thanks Gwendal, these were some excellent comments and insights.

Glenn

-------Gwendal LE GRAND-------
mailto:Gwendal.Le-Grand@lip6.fr tel: +33 (0) 1 44 27 75 12
http://www-rp.lip6.fr/~legrand fax: +33 (0) 1 44 27 74 95
Universite Pierre et Marie Curie, Laboratoire LIP6-CNRS, Bureau C646
8 Rue du Capitaine Scott, 75015 Paris, France