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

Nalini Elkins <> Wed, 16 October 2013 13:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 47BE611E82AA for <>; Wed, 16 Oct 2013 06:41:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.382
X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id J4J3-3NKt1VE for <>; Wed, 16 Oct 2013 06:41:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0BC6D11E8260 for <>; Wed, 16 Oct 2013 06:41:09 -0700 (PDT)
Received: from [] by with NNFMP; 16 Oct 2013 13:41:09 -0000
Received: from [] by with NNFMP; 16 Oct 2013 13:41:09 -0000
Received: from [] by with NNFMP; 16 Oct 2013 13:41:09 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 81911 invoked by uid 60001); 16 Oct 2013 13:41:08 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1381930868; bh=PXTBaoBK2gyima4oe58XWR+6cc4gjXMt/q5XMgvfHWs=; 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:Content-Transfer-Encoding; b=Y8wXcmn5ZATyCGplafZEXFiPGCxQHyU5RSh5zRMZho0PkTCinAbUgTBm81VmruPaZpcKhMa+qCwcAcSF68el9XAo6DQLHLwwmeDxL8ZLFzZgRL91QVyFUQTG9ityzMhHVITCDpRWp5kL985qakkFZZe5bHacY2TIB3YeQYQ/ypQ=
X-YMail-OSG: yPUi0tUVM1nlfy5zZ0Nqz5jVRtwJgJtxrCo7gdr_VOL5hq1 uiuJpgWHYYDs9AVZkxCZN0anvtPYDvG_mS_bMckAVgAuWOWZ3at5Jw5T8_Ll JpM8u8Mw7zXBm_WjFCkEfmkEIZOqRMTEoFtFpvuMxdMqEvhpORuZT27QRng2 rjCpiEAFa7tqZ.YdqvORIBmiVW.zsIiCW1I3MBNP2UcAU1UqtW4hBeCJz2rl mcyskhosTxLvuExgrl_GR4uvz4kAMIh5MntAGtAqQVdg.t4r0NDqnnbAI6f. OpoUgmpwnRFFH67UM.KiQW23eiwrC0LfmcfCVmVllYFGH22fXpzlBc97yrMj khH0TpRtLkah_STBDH5sRDy_ZizHvRZTvqwlz6aIFnp_pQv2zVWKxqzSLWna KCDLAVOmqbv7QV0BOmVbxfs3iEDNWr1h_3kkMr08nrFDOX0Cg8EVe.p4muHU 86p3pkOvhhVQxbyPs6cavM0Q_u.19_9qrJRquyta3EhIrg7MuHAoYKyUSVWO VQX7MsUuIPbuDaCI6.FHtbreCs1WZKUyybA5tC3fYEX8zEgwLtUcbMCngId0 f98uO3uTofRiqelam__tVz0U4kkBzwpJCIjF.4A--
Received: from [] by via HTTP; Wed, 16 Oct 2013 06:41:08 PDT
X-Rocket-MIMEInfo: 002.001, PiBJIGhhdmUgcmVhZCB0aGlzIGRyYWZ0LgoKPkFsbCBpbiBhbGwgaXQgc2VlbXMgcmF0aGVyIHNpbXBsaXN0aWMsIGFuZCBJIGNhbid0IGhlbHAgdGhpbmtpbmcgdGhhdAo.dGhlcmUncyBtdWNoIG1vcmUgdG8gdGhpcyB0aGFuIGlzIGV4cHJlc3NlZCBpbiB0aGUgZHJhZnQuCgpZZXMuIMKgVGhlcmUgaXMuIMKgU2VlIGJlbG93LgoKPkZvciBleGFtcGxlLCB0aGUgc2VydmVyIHRpbWUgY2FsY3VsYXRpb24gc2VlbXMgdG8gYXNzdW1lIHRoYXQgYSByZXNwb25zZQo.cGFja2V0IGhhcyB0byBiZSBzZW50IGltbWUBMAEBAQE-
X-Mailer: YahooMailWebService/
References: <> <> <>
Message-ID: <>
Date: Wed, 16 Oct 2013 06:41:08 -0700 (PDT)
From: Nalini Elkins <>
To: Ray Hunter <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: v6ops WG <>, 6man WG <>, "" <>
Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-03.txt
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Nalini Elkins <>
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Oct 2013 13:41:22 -0000

> 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.

>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.

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.