Subject: [MIPSHOP-MIH-DT] [Fwd: feedback on draft-ietf-mipshop-mis-ps]

From: Telemaco Melia <[email-masked]>
Date: Wed, 17 Oct 2007 17:22:12 +0200

Juan Carlos,

I started to check the comments received from the AD review (Lars also 
commented about the multiplexing issue)
In the attached email you can check the text about the multiplexing issue.
I was checking the figure with the intention to shape the text but I got 
the following doubt.
It is really required multiplexing support in the node supporting 
multiple MoS?
In case of one node (with mode than one MoS) to multiple nodes model I 
guess that the MSTP will simply open a socket to different IP addresses.
Can we say we do not need multiplexing?
In case of one node to one node communication (being both nodes multi 
MoS enabled) we might need multiplexing. Is this an MSTP task or MIH task?

I feel like this requirement is not well explained. Either we make it 
more clear or we drop it.

What do you think?

Tele

Subject: feedback on draft-ietf-mipshop-mis-ps
From: Lars Eggert <[email-masked]>
To: [email-masked], Mipshop Chairs <[email-masked]>
Cc: Magnus Westerlund <[email-masked]>, Godred Fairhurst <[email-masked]>, Jari Arkko <[email-masked]>
Date: Fri, 28 Sep 2007 16:00:36 +0300

Hi,

I briefly looked at the MIH requirements in draft-ietf-mipshop-mis- 
ps-03 and have a few comments:

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

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

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

Lars
_______________________________________________
MIPSHOP-MIH-DT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt