Subject: [mpls] Transport problems in draft-ietf-mpls-in-udp-05.txt

From: [email-masked]
Date: Sat, 8 Feb 2014 09:10:38 -0000

I have three comments on the updated draft:

(1) The current text informatively cites RFCs that it normatively relies
upon.

The choice of words in revision 05, section 3 seems quite odd to me:

" If the UDP checksum needs to be disabled for performance or
implementation reasons,
the considerations described in [RFC6935] [RFC6936] MUST be examined."

Do we require people to examine standards-track documents for
"consideration" or to comply with the requirements? I think the latter.

If the UDP checksum needs to be disabled for performance or implementation
zero checksum with IPv6, it MUST use the method in RFC6935, including the
requirements defined in section 5 of RFC 6936.

The text should either say MUST NOT use a zero checksum with IPv6, or it
needs to cite these as normative references. Both of these were published
as Proposed Standard, not as informational/BCP guidelines.

---

(2) Does it meet the requirements dictated by the under-lying protocol?

If the intention is to allow the method in RFC6935 is to be used, does the
method comply with the requirements for tunnels in section 5 of RFC 6936?
- Reading the text I can not see whether these specific requirements would
be met by this use-case or not.

---

(3) The new text improves the use-case explanation, but does not appear to
explain this.

I'm not sure what this means:

Section 5:

"Given the
   fact that the MPLS-in-GRE and MPLS-in-IP [RFC4023] encapsulation
   technologies have been successfully deployed within a SP network or
   networks of an adjacent set of co-operating SPs which is a
   restricted network environment without any congestion control
   mechanism and the fact that the current MPLS technology couldn't
   provide congestion control without major changes, the MPLS-in-UDP
   encapsulation MUST only be deployed within a SP network or networks
   of an adjacent set of co-operating SPs as well.   mechanism and the
fact that the current MPLS technology couldn't
   provide congestion control without major changes,"

So, I agree RFC5405 provides applicable guidance on congestion control. To
me, there are two paths that this can go:

1) The specification is only for use within controlled environments where
there is pre-provisioned capacity. This appears to be what is currently
stated. In this case, I think this really needs to be clearly called-out
in the abstract and introduction - at the moment it's veiled.

2) The specification is not intended for use on pre-provisioned capacity
paths. In which case, I do not understand from the text why there can be
no control loop for this deployed environment.

I do not understand why this could not include some form f circuit-breaker
function that prevents excessive congestion overload. The text above seems
to try to avoid discussing this, by hinting (I think) that it should only
be used with pre-assigned capacity within controlled environments, but to
me at least this isn't yet clear. Congestion control isn't just TCP-like
rate adaptation.

In summary, this text really needs review by someone with transport
expertise. Before that review, the WG need to decide if the case for
deployment is based, as it currently states on "reserved path capacity" 
"where the congestion control is not a concern".

---

Gorry

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 10 Feb 2014 03:22:47 +0000

Hi Gorry,

Thanks for your comments. Please see my response inline.

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]]
> 发送时间: 2014年2月8日 17:11
> 收件人: [email-masked]
> 抄送: [email-masked]; [email-masked]
> 主题: Transport problems in draft-ietf-mpls-in-udp-05.txt
> 
> (1) The current text informatively cites RFCs that it normatively relies upon.
> 
> " If the UDP checksum needs to be disabled for performance or implementation
> reasons, the considerations described in [RFC6935] [RFC6936] MUST be
> examined."
> 
> The text should either say MUST NOT use a zero checksum with IPv6, or it needs
> to cite these as normative references. Both of these were published as Proposed
> Standard, not as informational/BCP guidelines.

OK, I will move these two RFCs to the normative reference list in the next version.

> If the intention is to allow the method in RFC6935 is to be used, does the method
> comply with the requirements for tunnels in section 5 of RFC 6936?
> - Reading the text I can not see whether these specific requirements would be
> met by this use-case or not.

I wonder whether the text (see below) proposed by Curtis in this regard looks fine to you.

<text proposed by Curtis>

>       The usage of this field is as defined in the current UDP
>       specification [RFC768].  UDP allows the UDP checksum to be set
>       to zero indicating that no checksum was computed.  Except in
>       extroidinary cases, non-zero UDP checksum SHOULD be used. The
>       considerations described in detail in [RFC6935] [RFC6936] MUST
>       be examined if UDP checksums need to be disabled for performance
>       or implementation reasons.  UDP checksum should only be disabled
>       on private networks or where MPLS in UDP encapsualation is added
>       by a service provider with MPLS in UDP traffic entirely confined
>       to the network of that service provider or within cooperating
>       service providers with explicit permission.
> 
>       Where it is not possible to use full UDP checksum, and if using
>       UDP-Lite [RFC3828] is feasible, UDP-Lite SHOULD be used rather
>       than UDP with disabled checksums.

</text proposed by Curtis>

Or do you expect to add the following text further to the above text.

                "...Specifically, the UDP checksum MUST NOT be disabled 
                unless 1) the MPLS payload is Internet Protocol (IPv4 or IPv6) packets and the inner packet
                integrity checks is available; 2) or the MPLS payload is non-IP packet but it is specifically designed
                for transmission over a lower layer that does not provide a packet integrity guarantee.

> So, I agree RFC5405 provides applicable guidance on congestion control. To me,
> there are two paths that this can go:
> 
> 1) The specification is only for use within controlled environments where there is
> pre-provisioned capacity. This appears to be what is currently stated. In this case,
> I think this really needs to be clearly called-out in the abstract and introduction -
> at the moment it's veiled.

Yes, this is the current rough consensus (i.e., restrict the applicability of this technology within controlled environments) reached after long discussions. That's why the applicability statement is added to the introduction section and abstract section.

> 2) The specification is not intended for use on pre-provisioned capacity paths. In
> which case, I do not understand from the text why there can be no control loop
> for this deployed environment.
> 
> function that prevents excessive congestion overload. The text above seems to
> try to avoid discussing this, by hinting (I think) that it should only be used with
> pre-assigned capacity within controlled environments, but to me at least this
> isn't yet clear. Congestion control isn't just TCP-like rate adaptation.

I wonder whether the below text proposed by Curtis in this regard looks fine to you. If you believe it isn't yet clear, would you please suggest any text which could make it more clear?

<text proposed by Curtis>

> +     MPLS-in-UDP is applicable in limited circumstances (See Section
> +     1.3).  If deployed in a manner consistent with this
> +     applicability statement, then
>       guidelines for UDP tunnels as defined in Section 3.1.3 of
>       [RFC5405] SHOULD be followed. Specifically, as stated in Section
>       3.1.3 of [RFC5405]:
> 
>         "some bulk transfer applications may choose not to implement
>         any congestion control mechanism and instead rely on
>         transmitting across reserved path capacity. This might be an
>         acceptable choice for a subset of restricted networking
>         environments, but is by no means a safe practice for operation
>         in the Internet."
> 
> +     This usage is consistent with
>       MPLS-in-GRE and MPLS-in-IP [RFC4023]
> +     which have been
>       successfully deployed
> +     in deployments consistent with the applicability of MPLS-in-UDP
> +     defined in Section 1.3 and have been deployed
>       without any congestion control mechanism.
</text proposed by Curtis>

Best regards,
Xiaohu

> In summary, this text really needs review by someone with transport expertise.
> Before that review, the WG need to decide if the case for deployment is based,
> as it currently states on "reserved path capacity"