Re: [Rtg-dt-encap-considerations] Some comments on draft

Erik Nordmark <nordmark@sonic.net> Mon, 09 March 2015 17:40 UTC

Return-Path: <nordmark@sonic.net>
X-Original-To: rtg-dt-encap-considerations@ietfa.amsl.com
Delivered-To: rtg-dt-encap-considerations@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0971A911B for <rtg-dt-encap-considerations@ietfa.amsl.com>; Mon, 9 Mar 2015 10:40:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFTu779HtQWW for <rtg-dt-encap-considerations@ietfa.amsl.com>; Mon, 9 Mar 2015 10:40:45 -0700 (PDT)
Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33C61A9119 for <rtg-dt-encap-considerations@ietf.org>; Mon, 9 Mar 2015 10:40:45 -0700 (PDT)
Received: from [172.22.227.238] ([162.210.130.3]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t29Heg2d014028 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 Mar 2015 10:40:42 -0700
Message-ID: <54FDDB1A.4010309@sonic.net>
Date: Mon, 09 Mar 2015 10:40:42 -0700
From: Erik Nordmark <nordmark@sonic.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Tom Herbert <tom@herbertland.com>
References: <CALx6S364kroAzBFOW+r1Ne+R0p=mG3kvNyS_r6dQi7i4TP9OOQ@mail.gmail.com>
In-Reply-To: <CALx6S364kroAzBFOW+r1Ne+R0p=mG3kvNyS_r6dQi7i4TP9OOQ@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Sonic-CAuth: UmFuZG9tSVbtSb0rIhepfz3L3KMj04iUNbMPE++gqiCycLrSBRm5u2W9nn8TtDjlUIiy6d4Mnpva8jWdvvUSdcklz5cfcT48
X-Sonic-ID: C;wH6WaIPG5BG4nb5YxQPdhw== M;WgHAaIPG5BG4nb5YxQPdhw==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-dt-encap-considerations/-ehUiYCirGX0GLXli1YVG46vCSo>
Cc: rtg-dt-encap-considerations@ietf.org
Subject: Re: [Rtg-dt-encap-considerations] Some comments on draft
X-BeenThere: rtg-dt-encap-considerations@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Design Team on Encapsulation Considerations discussion list <rtg-dt-encap-considerations.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dt-encap-considerations>, <mailto:rtg-dt-encap-considerations-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-dt-encap-considerations/>
List-Post: <mailto:rtg-dt-encap-considerations@ietf.org>
List-Help: <mailto:rtg-dt-encap-considerations-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dt-encap-considerations>, <mailto:rtg-dt-encap-considerations-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Mar 2015 17:40:48 -0000

Thanks for the careful review. I've applied the edits except as noted below.

On 3/7/15 3:59 PM, Tom Herbert wrote:
> Abstract:
>
> in the case when->in the case that
>
> Section 2
>
> The encapsulation protocols typically->Encapsulation protocols typically
>
> And NIC hardware->NIC hardware
>
> Section 4
>
> 2nd bullet is a lttle wordy. I think this is saying we assumed mostly
> stateless encapsulation protocol

"stateless" means different things to different readers.

But it can be made shorter. How about:
<t>Focus on the class of encapsulations that would run over IP/UDP. That 
was done to avoid being distracted by the data-plane and control-plane 
interaction, which more significant for protocols that are designed to 
run over "transports" that maintain session or path state.</t>

>
> Section 5
>
> The goal to->The goal is to
>
> the need to be aware->they need to be aware
>
> The section on IPv6 flow label is still a little conservative I think.
> We already have RFC 6438 that described use of flow labels with
> tunnels. Also, this might be better positioned as a way to provide
> additional entropy (14 bits for tunnels is going to be a little light
> in some contexts).

I reworded it after the call on Thursday. The last sentences say:
Currently the leaning is towards recommending using the UDP encaps for 
both IPv4 and IPv6 underlay. The IPv6 flow label can be used for 
additional entropy if need be.


>
> Section 8
>
> some way to indicate which encapsulation header will follow... not
> clear. This saying: some way to indicate next protocol?
It is really about the encaps, but the preceeding header could also 
carry non-encaps.
How about wording it as:
The transport delivery mechanism for the encapsulations we discuss in 
this document need some way to indicate which encapsulation header (or 
other payload) comes next in the packet.

>
> Bullet 2. I don't understand the part about "bringing in protocol
> numbers that don't make sense".

It is trying to capture the questions like would it make sense to run 
OSPF, ICMPv6, etc directly on top of the encaps.

Is it more clear to say:
"that would never be used directly on top of the encaps protocol"?


>
> Section 10
>
> A single marker in the encaps... there was discussion in nvo3 such a
> plan and it had some problems By using a single bit the epochs are
> forced to be rather coarse. Other problems with part about using a s
> single bit to do 1-way latency. I think this paragraph should be
> removed or expanded with more detail.
I'm puzzled because earlier versions suggested encaps reserving room for 
multiple bits and you convinced me that didn't make any sense. Now you 
seem to be saying that one bit isn't sufficient and there has to be 
multiple bits.

I'll preface it and reword as "There has been suggestions that one (or 
more) marker...".

>
> Section 11: Still needs to be cleaned up. I will try to do that.
>
> Section 13: Data centers may be very highly optimized for their own
> internal traffic by assuming that all internal traffic in under a
> specific congestion control. That hash allowed us to size and carve
> buffers in very specific ways. With cloud, we introduce 3rd party
> stacks, that may implement CC, but not one which is conformant with
> internal traffic. This is creating problems and may be the motivation
> for true cc at encap layer
What edit are you suggesting?

>
> Last paragraph: Rate limiting is not the same thing as congestion
> control (unless there's very active management of rate)
What edit are you suggesting?
>
> Section 14
>
> There is little value in the portion of the UDP checksum... true in
> terms of being redundant to an encapsulated checksum, however there is
> value in leveraging the outer checksum to validate inner one using
> common NIC offload features.
What edit are you suggesting?
This will be mentioned in the hardware friendly offload text that you 
provided.

>
> For description of partial checksum maybe add: This checksum would
> cover the encapsulation header and a pseudo header that includes at
> least the IP addresses and ports.
Doesn't "the same partial-checksum concept as UDP-Lite" already say that?

>
> For NAT problem this can be solved with an additional field that holds
> the checksum of the original IP addresses.

I don't think we need to propose solutions here. Pointing out the issue 
should be sufficient.
>
> Section 17
>
> Once again the idea of spraying packets of single flows has been brought up:
> https://www.cs.purdue.edu/homes/kompella/publications/infocom13.pdf
>
> It's probably more correct to say that TCP is optimized for in order
> delivery, but can handle ooo. Some other protocols (non-IP) might have
> much more difficulty.
I don't see where that text would fit into the current text.
>
> Section 18
>
> Keep encap headers small-- can we be more specific on what small means?
42 bytes?  ;-)

But perhaps we don't understand the question yet.

    Erik

>
> _______________________________________________
> Rtg-dt-encap-considerations mailing list
> Rtg-dt-encap-considerations@ietf.org
> https://www.ietf.org/mailman/listinfo/rtg-dt-encap-considerations
>