Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt

Nalini Elkins <nalini.elkins@insidethestack.com> Wed, 23 October 2013 02:47 UTC

Return-Path: <nalini.elkins@insidethestack.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEBB411E8275 for <v6ops@ietfa.amsl.com>; Tue, 22 Oct 2013 19:47:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.382
X-Spam-Level:
X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4SYxmUedkcf for <v6ops@ietfa.amsl.com>; Tue, 22 Oct 2013 19:47:42 -0700 (PDT)
Received: from nm22-vm4.access.bullet.mail.gq1.yahoo.com (nm22-vm4.access.bullet.mail.gq1.yahoo.com [216.39.63.110]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8EE11E80F6 for <v6ops@ietf.org>; Tue, 22 Oct 2013 19:47:42 -0700 (PDT)
Received: from [216.39.60.165] by nm22.access.bullet.mail.gq1.yahoo.com with NNFMP; 23 Oct 2013 02:47:42 -0000
Received: from [216.39.60.243] by tm1.access.bullet.mail.gq1.yahoo.com with NNFMP; 23 Oct 2013 02:47:42 -0000
Received: from [127.0.0.1] by omp1014.access.mail.gq1.yahoo.com with NNFMP; 23 Oct 2013 02:47:42 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 27151.64201.bm@omp1014.access.mail.gq1.yahoo.com
Received: (qmail 47023 invoked by uid 60001); 23 Oct 2013 02:47:41 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1382496461; bh=cp/HBCX/azKn4xEzvCECFX47EmKLyeH/PkzW2nQkVfg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=cCILD0lcg4yCQrbCKIsOasldBSmzwrTwj00/2xYq+zJyjhhy6n3Cf5eMNxUWwt01dbFxx0V6L9Bz02kC8gSPYcH27aQlZXRuFHSS5R12P1bDmuwMFSb5Tu1pqV/ecSbv2ZNdO3lx3MZm0XAqscPSdZmaEKL+ZqQTSnbg3bDyZ20=
X-YMail-OSG: QPQC_PsVM1kZD_X6gftynY4P1O7fpNe3sXgZmv80zWVACon 0c4YSAvjLK7lrM9GBYC1tsImxDhj_Yv_c9JUzlt89s57taT5hkZaFLU3wura dbkpAoGoL398Wp_SPxc6_I5D8ZqfG2.auj7MojOJvR.m6gH7_i1JjdrNoKAW KskYXNZCdRS.xDt2RdTzdHoQq2FFHxACNh3gXI3OAQpAnek2xNd96ar0Fb0y G3T9Llgg_uvxyqa_4kkh3_FFtTwno0mVzqPSfsH5c6fFo6hvdA2g5OdHpDVD 8moyZzinaLOczBgi6tiUzZU9vrCtcx2_FkiB4KuwpHr0nKtpC4i5mp8NQbLZ ydi5VRWZ2QxsuV7DwQ5.VA.2PBKscBTAy5xUmi5d568mNhbjvUE.KuFWXUIC dDlNxkMQaR_dHsLO9f9L_vK3On292mgnHeNomXnjjTjkikPpCCpnhG7Hkmn. xVLQmLtyHx.y1jy8PitoDE4wJQuqOJmDa.0K9xSPXID3gu_DzAS12QmtSjsb CpIWqr1JMPLCSwVgFmkczX7Vzwsr8exMm__v5fIfD3TbT_1kih2VQJFwGrQK PXoNxb6DajkwKdVcCiJj_xJ1Aspkil4VXwKHorw--
Received: from [24.130.37.147] by web2802.biz.mail.ne1.yahoo.com via HTTP; Tue, 22 Oct 2013 19:47:40 PDT
X-Rocket-MIMEInfo: 002.001, Cgo.IE5hbGluaSBFbGtpbnMgPG1haWx0bzpuYWxpbmkuZWxraW5zQGluc2lkZXRoZXN0YWNrLmNvbT4KPiAyMiBPY3RvYmVyIDIwMTMgMDA6NTgKPj7CoCAxKSBlbmNvZGluZyBoYXMgdG8gYmUgZmFzdCwgYnV0IGRlY29kaW5nIGRvZXMgbm90Cj4KPiBUcnVlCj4KPj7CoCAyKSBhIG5vZGUncyBjbG9jayBjb3VsZCBiZSBlaXRoZXIgaW4gb3VyIG91dCBvZiBzeW5jaCB3aXRoIHNvbWUgbm90aW9uYWwKPj7CoCBtYXN0ZXIgY2xvY2sgKGUuZy4gdmlhIE5UUCkKPj7CoCAzKSB0d28gY2xvY2tzIGNvdWxkIGJlIGkBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.160.587
References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <526616C4.40304@globis.net>
Message-ID: <1382496460.46942.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com>
Date: Tue, 22 Oct 2013 19:47:40 -0700 (PDT)
From: Nalini Elkins <nalini.elkins@insidethestack.com>
To: Ray Hunter <v6ops@globis.net>
In-Reply-To: <526616C4.40304@globis.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-153701192-410707112-1382496460=:46942"
Cc: v6ops WG <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>
Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Nalini Elkins <nalini.elkins@insidethestack.com>
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Oct 2013 02:47:49 -0000


> Nalini Elkins <mailto:nalini.elkins@insidethestack.com>
> 22 October 2013 00:58
>>  1) encoding has to be fast, but decoding does not
>
> True
>
>>  2) a node's clock could be either in our out of synch with some notional
>>  master clock (e.g. via NTP)
>>  3) two clocks could be in synch to a master source, but the master
>>  sources may themselves not share a common source (one sourced from GPS,
>> one from DCF77)
>> 4) the key to being able to perform the end to end calculations is
>> whether two communicating nodes are synchronised to the same master
>> clock (within some level of error/jitter)
>> 5) the absolute time is not particularly important
>
>
> This is true for PDM 1 only.  PDM 2 does not require time synchronization.
>
>>  Q1. Why do you want to encode differences as deltas in the case of an unsynchronised/ free running clock?
>>  Isn't that slow, and difficult for hardware implementations to achieve (e.g. TCP offload)? Doesn't it also require maintaining large amounts of state in the sending node.
>>
>
> 1. I think that it is going to be interesting to see how hardware is going to handle TCP offload with IPv6 extension headers.   I do not see why PDM 2 would be so much harder than PDM 1 for an OS.
> Can you tell me which end host operating systems are doing TCP offload in hardware?  


>IMHO Not a relevant question. As a standards body we should be looking
>to the future. There are many operations that are delegated to microcode.

>If you specified the packet with one single way of encapsulating
>timestamps, then hardware or interface microcode could add the timestamp
>at the last possible moment before the packet reached the wire, without
>having to examine the original packet contents, or knowing the context
>of the communicating nodes. I think that's very desirable.

Sure.   Sounds good!  Also looking to the future, then I will speculate that we will likely have more and better time synchronization also.


> I know some OS's which process TCP segmentation in hardware.    But at this point, the packet is already crafted.  Also some do IP checksum offload in hardware but that does not apply to IPv6 as there is no IP header checksum.

>
>
> 2.  End hosts already maintain quite a bit of state.  Every OS has control blocks to handle events such as TCP duplicate packets, round trip time, congestion window, etc.   We are NOT suggesting
> that the PDM headers be used in middle boxes.  That is, we are NOT asking routers to maintain state.


>So what? Why add to the problem?

Yes.  Just saying that we are not CREATING the problem.

>Why does the timestamp require synchronisation with that other TCP state?

It doesn't.  Just mentioning other reasons why state is maintained.

>Isn't it better to define a solution that is independent of the upper layer header transport protocol?

Yes.  Our solution IS independent.  I think my analogy actually confused the issue!

><heresy>  Why not allow middleboxes (or node hardware) to insert the timestamp header on the fly?</heresy>

Interesting idea!

>
>>  Why not just encode the timestamp as-is and perform the appropriate difference calculation during decoding?
>
> If clocks are out of synch, you could end up having it look like you received the packet before you sent it.

> No. I'm not suggesting you use the same decoding algorithm: only that you define a single common encoding algorithm that combines all the information required for PDM 1 and PDM 2 calculations. Having to chose
>which packet encoding to use in advance is problematic IMHO. 

We will look at this.   I am also meeting with a couple of the end host OS vendors to get their viewpoint on the PDMs.   Their engineers have good opinions on what the problems might be with actually creating PDMs.
I should have that info before Vancouver.

>>  Q2. Why do you need two separate packet formats at all?
>
>>  Why not have a common format for all cases, containing a timestamp based
>> on the local clock, plus an optional field containing a flag that states
>> if the local timestamp is coordinated to some master clock, plus an
>> identifier for the master clock.
>
>> You could then encode whether a node had a free-running clock (case 2),
>> a synchronised clock (case 1), and whether it was synched via NTP to
>> some stratum 0 source e.g. GPS, and also some identification of the
>> stratum 1 source (IPv6 address).
>
>> Two communicating nodes could then use e.g. NTP trace to see if they
>> shared a common clock source or not, before performing their calculations.
>
> We are trying to craft a solution with PDM 2 for those situations where time synchronization is not practical, possible or desired.

>I understand the aim, but let me ask my question a different way.

>Imagine there are nodes A&B that with clocks synched to DCF77.
>Imagine there are nodes C&D that with clocks  synched to GPS.
>Node E has free running clock (possibly because the GPS receiver is down).

>Which packet format PDM type 1 or PDM type 2 do you use between each
>pair of nodes, and how does the sending node know that?

>Scale this solution to 100K hosts.

Good question.  We were thinking that each node would start with PDM 1 and then if the other side could not do PDM 1, then it would drop back to PDM 2.
But, the clock issue is good.  Now, my understanding is that clock difference has more to do with Stratum levels.    But, I am not the NTP expert in the group. 
I am just wondering (leaving off Node E) how much clock difference would there be?   What do you think? I have a meeting with my team tomorrow & will bring this up for discussion.

>
> ------------------------------------------------------------------------


-- 
Regards,
RayH