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

Ray Hunter <v6ops@globis.net> Wed, 16 October 2013 14:14 UTC

Return-Path: <v6ops@globis.net>
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 C9B3B11E81D3; Wed, 16 Oct 2013 07:14:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 2e4v9xPSUB-k; Wed, 16 Oct 2013 07:14:28 -0700 (PDT)
Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2322C11E81DB; Wed, 16 Oct 2013 07:14:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id E4D05870074; Wed, 16 Oct 2013 16:14:24 +0200 (CEST)
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucbpHUt47nty; Wed, 16 Oct 2013 16:14:24 +0200 (CEST)
Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id C2E69870073; Wed, 16 Oct 2013 16:14:24 +0200 (CEST)
Message-ID: <525E9F3F.2020600@globis.net>
Date: Wed, 16 Oct 2013 16:14:23 +0200
From: Ray Hunter <v6ops@globis.net>
User-Agent: Postbox 3.0.8 (Macintosh/20130427)
MIME-Version: 1.0
To: Nalini Elkins <nalini.elkins@insidethestack.com>
References: <20131015235832.2100.62094.idtracker@ietfa.amsl.com> <1381881831.35197.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <525E9152.60209@globis.net> <1381930868.81291.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com>
In-Reply-To: <1381930868.81291.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
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-03.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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, 16 Oct 2013 14:14:28 -0000

> Nalini Elkins <mailto:nalini.elkins@insidethestack.com>
> 16 October 2013 15:41
>> I have read this draft.
>
>> All in all it seems rather simplistic, and I can't help thinking that
>> there's much more to this than is expressed in the draft.
>
> Yes.  There is.  See below.

Then I would humbly suggest that you consider keeping this as a clean
standards track draft just defining the message formats for the
transport (in 6man WG) = Section 1 & 2, and leave the use cases,
architecture, and calculations to other informational drafts (e.g. in
ippm) = Section 3,4. c.f. SNMP
>> For example, the server time calculation seems to assume that a response
>> packet has to be sent immediately by every application as soon as data
>> has been processed: every response requires a response.
>
> Not at all.
>
>> What additional processing is required to cater for cases where the
>> sender and the receiver simply have nothing to say to each other at that
>> point in time?
>
> Frankly, other than keep-alives, I have not seen this.  Please correct me if I am wrong.
>
> The logic for processing and making 'sense' of these metrics is much more complex than the fields to be sent.  This is as it should be.   The OS needs to send packets quickly.  After the fact, we can take our time and do analysis.
>
> What needs to be handled (at a minimum) are the following cases.  You may have more.
>
> 1.   Host clocks not synchronized - done
> 2.   IP fragmentation 
> 3.   Multiple sends from one side (multiple segments) 
> 4.   Out of order segments (PSN will go negative)
> 5.   Retransmits (PSN will go negative)
> 6.   One–way transmit only (ex. FTP)  (server delta will continually increase)
> 7    Delayed acks
> 8.   ACKs preceeding send for another reason
> 9    Proxy servers
> 10. Full duplex traffic
> 11. Keep alive (0 / 1 byte segments, larger segments)
> 12. No response from other side (your case - which I believe to fall under Keep Alives)  
> ,
>
> I have only provided the most basic case in this draft.   But, have thought a great deal about these others and how they would be handled.  I can provide packet flows for all these above to let you know how these can be handled.  Again, if you have more cases, I welcome your input.

6. one way transmit only (e.g.real time transports and streaming
protocols, although RTP has it's own timestamps based on NTP)

13. Drop without retransmit (real time transports)
14. Looped packets (where the same packet may pass the same point
multiple times without duplication)
15. Multihoming via Shim6
> Additionally, I am in no way suggesting that this be the ONLY metric that is used to calculate errors or performance.  For example,  if you look at my definition of the "Retransmit Duplication" metric, you will see that TCP sequence number is used in addition to the Packet Sequence Number to good effect. 
>  
>

-- 
Regards,
RayH