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

From: Sam Xia <[email-masked]>
Date: Sat, 29 Sep 2007 09:51:57 +0800

Best Regards, Sam Xia
-----Original Message-----
From: Lars Eggert [mailto:[email-masked]] 
Sent: Friday, September 28, 2007 9:01 PM
To: [email-masked]; Mipshop Chairs
Cc: Magnus Westerlund; Godred Fairhurst; Jari Arkko
Subject: feedback on draft-ietf-mipshop-mis-ps

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

---

From: Sam Xia <[email-masked]>
Date: Sat, 29 Sep 2007 09:52:06 +0800

Best Regards, Sam Xia
-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Friday, September 28, 2007 9:17 PM
To: Lars Eggert
Cc: [email-masked]; Mipshop Chairs; Magnus
Westerlund; Godred Fairhurst
Subject: Re: feedback on draft-ietf-mipshop-mis-ps

Thanks. Authors, chairs, please take these comments into account as well for
your new document revision.

Jari

Lars Eggert kirjoitti:
> 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
>>       1.  Assume the transport cannot be guaranteed to support reliable
>>           situations, and provide a very basic acknowledgement mechanism
>>           something more serious has occurred than a packet drop (since
> 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.)
>
> 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.
>
>>    support multiple applications (or modes of operation) to support the
>>    particular requirements of the Information Exchange being carried out