IEEE 802.21 Mobility Services Framework Design (MSFD)
draft-ietf-mipshop-mstp-solution-12

I support Pasi's discuss.  TLS has shown to be a deployable privacy
solution in the real world.  In addition to privacy, it includes authentication support that works in some scenarios or when combined
with SASL/EAP/HTTP-auth or some other authentication framework), but it
has lots of knobs that have to be specified when a protocol chooses to
use it.  We've had some mistakes when binding it to application protocols
that caused real deployment problems and had to be corrected (the most
notable is allowing "STARTTLS" to be advertised as a capability by a
server even if no server certificate is installed).

I strongly recommend getting this right early rather than botching it
and having to work around bad deployment practices.

Support PASI discuss.

I will let the others hold the discuss but, they must be cleared.

Last Edited Date: 2008-09-25

Section 6.1., paragraph 4:
>    In terms of dealing with short messages, TCP has the capability to
>    concatenate very short messages in order to reduce the overall
>    bandwidth overhead.  However, this reduced overhead comes at the cost
>    of additional delay to complete an MIH transaction, which may not be
>    acceptable for CS and ES services.

  The only delay with TCP (assuming Nagle is turned off) is the
  connection setup delay, i.e., a delay on the very first MIH exchange.
  Because subsequent exchanges go over an already established
  connection, there is no additional latency. (Other than head-of-line
  blocking under heavy loss due to retransmissions.)


Section 6.2., paragraph 1:
>    Therefore a burst of either
>    short CS/ES messages or long IS message exchanges (in the case where
>    multiple MIH nodes request information) may lead to network
>    congestion.  While the built-in rate-limiting controls available in
>    TCP may be well suited for dealing with these congestion conditions,
>    this may result in large transmission delays that may be unacceptable
>    for the timely delivery of ES/CS messages.

  TCP backs off if there is packet loss, and yes, performance may
  degrade. But UDP is no magic bullet, either - UDP packets in such
  scenarios are lost in the same way as TCP packet, and delivery over
  UDP is unlikely to be more timely than with TCP.


Section 6.3., paragraph 3:
>    An MIH message is retransmitted if its corresponding MIH ACK is not
>    received by the generating node within a timeout interval set by the
>    MIHF.  This approach does not include an exponential backoff and
>    therefore tends to degrade more gracefully than TCP when the packet
>    loss rate becomes large, in the sense that the expected delay does
>    not increase exponentially.  The number of retransmissions is
>    limited, which reduces head-of-line blocking of other MIH messages,
>    but this can cause important ES/CS messages to be lost.  The default
>    number of retransmissions is set to 2 and retransmissions are
>    controlled by a timer with a default value of 10s.  No backoff
>    mechanism is specified.

  I don't buy this. If you wait 10s before the first retransmit and then
  try another one after 20s, TCP will have long retransmitted the lost
  packets, because its RTO is based on the RTT, which is typically much
  less than 10s. UDP will only be faster if much more aggressive timers
  are used here, which is problematic. I'd like to request that the text
  around what timers values are permissible be tightened using 2119
  language. (I believe this is part of Magnus' discuss, so I'll leave this
  as a comment for now. I may upgrade this to a discuss if Magnus'
  discuss doesn't include this bit.)


Section 6., paragraph 1:
>    Given the reliability requirements for
>    the MIH transport, it is assumed in this discussion that the MIH ACK
>    mechanism is to be used in conjunction with UDP, while it is
>    preferred to avoid using MIH ACKs with TCP since TCP includes
>    acknowledgement and retransmission functionality.

  Given the reliability requirements, shouldn't this text REQUIRE MIH
  ACKs with UDP and say they MUST NOT be used with TCP? (I can't come up
  with a reason to permit anything else.)


Section 6.3., paragraph 2:
>    If UDP is being used to carry MIH messages, MIH SHOULD use MIH ACKs.

  See above, I think your reliability requirements make this a MUST.


Section 6.1., paragraph 5:
>    The use of the PUSH bit can alleviate this problem by triggering
>    transmission of a segment less than the SMSS.

  The PUSH bit is not under the control of an application that uses TCP.
  I believe you mean that the Nagle algorithm (RFC896) should be
  disabled.


Section 6.2., paragraph 3:
>    o  If MIHF knows the RTT, the rate can be based upon this

  How?

Section 6.3., paragraph 1:
>    For TCP, the retransmission timeout is adjusted according to the
>    measured RTT.  However due to the exponential backoff mechanism, the
>    delay associated with retransmission timeouts may increase
>    significantly with increased packet loss.

  And that is a *feature* - it's why Internet congestion control works.

[I have cleared my discuss and moved this to a comment after discussion with the 
sponsoring AD...]

Section 5 puts a lot of effort into differentiating between MoS discovery for MoSh, MoSv, and
MoS3.  However, I was surprised to find that these terms never appear in the remainder of the
document.  That is, the transport options in section 6, transport flows in section 7, and
security considerations in section 8 only refer to MoS in general.  I would think that the source
of my mobility services would impact the selection of a transport, and would have security
implications.  (I don't think it impacts the flow, though.  Is that correct?)

Perhaps the implications are all second-order (e.g., MoS3 discovery using IS implies longer
messages which has impacts MIH message Size in 6.1 and rate in 6.2) ?