Subject: [MIPSHOP-MIH-DT] (no subject)

From: Sam Xia <[email-masked]>
Date: Thu, 11 Oct 2007 12:15:12 +0800

Tele and guys,

I have just summarized the comments about MIH-PS.  Please see the following
and the attachment.

1: Comment on PS
1.1 Comments from Jari Arko
1.1.1 comments on multihoming section of PS

It seems counter-intuitive that a component in the mobility infrastructure
wants to avoid 
using mobility mechanisms itself...

Sam> Just as I said before, I have the same feeling.

In any case, I think this item needs rethinking because the issue is not
just the use of a 
different link or path; when you are connected to multiple networks, it is
likely that you 
need to get information from *different endpoints*.

I would simply state here that the protocol needs to be capable of receiving
information 
from multiple endpoints at the same time and be able to change the
information source upon 
movements. 

Sam> Reasonable. A new requirement?

Then I would add that where a MIH session should survive a movement, it is 
expected that the mobility protocols deal with it.

1.1.2 comments on security section of PS
> The control and
>    maintenance of mobile nodes becomes challenging where authentication
>    and authorization credentials used to access a network are
>    unavailable for the purpose of bootstrapping a security association
>    for handover services.

I'm not sure I see why. I could imagine that at least information services
could be run 
based on web-like server-side certs. Or even unsecured in some cases, cf.
DHCP security.
But the next paragraph explains the issue better; I'd suggest deleting this
statement.

Sam> I think that what the draft is saying is the other thing than what jari
said. we should
clarify this point.

1.2 Comments from Lars Eggert
1.2.1 comments on reliability requirement of MSTP
>    Reliability:  Reliable delivery for some of the mobility  
> services may
>       be essential, but it is difficult to trade this off against the
>       low latency requirement.  It is also quite difficult to design a
>       robust, high performance mechanism that can operate in
>       heterogeneous environments, especially one where the link
>       characteristics can vary quite dramatically.  There are two main
>       approaches that could be adopted:
>
>       1.  Assume the transport cannot be guaranteed to support  
> reliable
>           delivery.  In this case, the Mobility Support Service itself
>           will have to provide some sort of reliability mechanism to
>           allow communicating endpoints to acknowledge receipt of
>           information.
>
>       2.  Assume the underlying transport will deal with most error
>           situations, and provide a very basic acknowledgement  
> mechanism
>           that (if no acknowledgement is received) will indicate that
>           something more serious has occurred than a packet drop  
> (since
>           these other types of error conditions are dealt with at the
>           transport layer).

This distinction doesn't make sense. Either the transport is reliable  
or it isn't. In the first case, there is no need to have any MIH- 
layer reliability. In the second case, you must have MIH-layer  
reliability. ("Will deal with most error situations" in case 2 means  
"unreliable", meaning you need the exact same mechanisms that in case  
1.)

Sam> I don't understand why there is no need to have any MIH-layer
reliability
in the first case.

1.2.2. comments on congestion control requirement of MSTP
>    Congestion Control:  A Mobility Service may optionally wish to
>       transfer large amounts of data, placing a requirement for
>       congestion control in the transport.  There is an interaction
>       between this requirement and that of the requirement for low
>       latency since ways to deal with timely delivery of smaller
>       asynchronous messages around the larger datagrams is required
>       (mitigation of head of line blocking etc.).

This sounds like congestion control is only needed when transferring  
large amounts of data. This is not the case. *All* transmissions need  
to be congestion controlled in some form. See Section 3.1.2 in draft- 
ietf-tsvwg-udp-guidelines for how to congestion control low-datarate  
applications.

Sam> reasonable.

1.2.3. Comments on Multiplexing
>    In addition to the above, it may be necessary for the transport to
>    support multiple applications (or modes of operation) to support  
> the
>    particular requirements of the Information Exchange being  
> carried out
>    between nodes.  This may require the ability to multiplex multiple
>    information exchanges into a single transport exchange (see figure
>    Figure 7) .

I don't understand what this means. (I also don't understand Figure 7.)

Sam> It seems that it is certain for the transport to support multiple 
applicaitons. I don't know why we should have this section. anything
else?

Best Regards, Sam Xia
_______________________________________________
MIPSHOP-MIH-DT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt

---

From: Telemaco Melia <[email-masked]>
Date: Fri, 19 Oct 2007 16:52:08 +0200

Sam,

I just provided yesterday a revised version of the PS (-04).
I am reading through your summary (since there was no subject I skipped 
the email) now..please check the file I posted and let me know if I 
missed anything.

Tele

Sam Xia wrote:
> ------------------------------------------------------------------------
>

-- 
Dr. Telemaco Melia			[email-masked]
Senior Research Staff Member		Tel: +49 (0) 6221 4342- 142
NEC Europe Ltd.
NEC Laboratories Europe
Network Division			
Kurfürsten-Anlage 36		
69115 Heidelberg
GERMANY	  

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: Sam Xia <[email-masked]>
Date: Wed, 24 Oct 2007 16:49:30 +0800

I don't see anything missed except that multiplexing issue is not dealed
with. some editorial issues as follows:
 
  Multihoming:  For some information services exchanged with the MN,
      there is a possibility that the request and response messages can
      be carried over two different links e.g. a handover command
      request is on the current link while the response could be
      delivered on the new link.  It is expected that the transport
      protocol is capable of receiving information via multiple links
      and to combine information beloning to the same session/
      transaction.  When mobility is applied the undelaying IP mobility
      mechanism should provide session continuty when required.
 
beloning-->belonging
continuty-->continuity

 Best Regards, Sam Xia 

  _____  

From: Telemaco Melia [mailto:[email-masked]] 
Sent: Friday, October 19, 2007 10:52 PM
To: Sam Xia
Cc: [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] (no subject)

Sam,

I just provided yesterday a revised version of the PS (-04).
I am reading through your summary (since there was no subject I skipped the
email) now..please check the file I posted and let me know if I missed
anything.

Tele

Sam Xia wrote: 

Tele and guys,

and the attachment.

1: Comment on PS

wants to avoid 

just the use of a 

likely that you 

information 

information source upon 

movements. 

The control and

   for handover services.

could be run 

DHCP security.

statement.

said. we should

clarify this point.

services may

reliable

          information.

mechanism

(since

          transport layer).

1.)

reliability

in the first case.

applications.

Sam> reasonable.

the

carried out

   Figure 7) .

else?

Best Regards, Sam Xia

  _____  

[email-masked]

-- 

NEC Europe Ltd.

NEC Laboratories Europe

Network Division			

Kurfürsten-Anlage 36		

69115 Heidelberg

GERMANY	  

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London
W3 6BL | Registered in England 2832014