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

[Ray Hunter <[e-mail]>]

> Nalini Elkins <mailto:[e-mail]>
> 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