Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

[Nalini Elkins <[e-mail]>]

Guys,

1.  RTP:  I do not think that it is pertinent.    I do not know what Dan is suggesting - that we change ALL applications to provide seq. no and timestamp?   Large companies use hundreds of applications running under TCP/IP.  This is completely undoable.

2.  Forcing of IPv6 fragmentation header.  We did discuss this in section 3: http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-packet-sequence-needed-00#page-11

It is as follows:

"The current IPv6 specification does not provide a packet sequence number or similar field in the IPv6 main header.  One option might be to force all IPv6 packets to contain a Fragment Header.  In packets which are entire in and of themselves, the fragment ID would be zero - that is, an atomic fragment. Why was a new destination option header defined rather than recommending that Fragment Header be used?


Our reasoning was that the PDM destination option header would provide multiple benefits : the packet sequence number and the timestamp to calculate response time. "

The second reason for not having a fragment header is that unfortunately, a number of firewalls, etc, drop packets which contain IPv6 fragment headers.  I find this to be unsuitable behavior which I hope will change .   But, it is the reality.


3.  TCP Sequence Number:  this was discussed in: http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-packet-sequence-needed-00#section-1.3

It is as follows:

"TCP Sequence number is defined in RFC0793[RFC0793].  Some have  proposed that this field will meet the needs of EDCO networks for a  packet sequence number.  Indeed, the TCP Sequence Number along with the
TCP Acknowledgment number can be used to calculate dropped packets, duplicate packets, out-of-order packets etc. That is, IF the packet flow itself reflects accurately what happened on the wire!
See Scenario 1 (Section 1.5.2) and Scenario 2 (Section 1.5.3) for what happens with packet trace capture in real networks. The TCP Sequence Number is, obviously, available only for TCP and not other transport protocols." 


Thanks,


Nalini Elkins
Inside Products, Inc.
[phone]
www.insidethestack.com



________________________________
From: Fred Baker (fred) <[e-mail]>
To: Dan Wing (dwing) <[e-mail]> 
Cc: "[e-mail]" <[e-mail]>; "[e-mail]" <[e-mail]> 
Sent: Saturday, June 1, 2013 7:47 AM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed



On May 31, 2013, at 5:48 PM, Dan Wing <[e-mail]> wrote:

> 
> On May 31, 2013, at 5:45 AM, [e-mail] wrote:
> 
>> A new draft has been posted, at http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-end-to-end-rt-needed. Please take a look at it and comment.
> 
> I read that document and draft-elkins-v6ops-ipv6-packet-sequence-needed.  Both the documents talk about how IPID is useful on IPv4 (if the sender is monotonically increasing the IPID, which is a necessity for the existing system to operate) and how routers sometimes send a packet twice (which is normal behavior of Ethernet) and that the monotonically increasing IPID helps distinguish Ethernet re-transmissions from host stack retransmissions.
> 
> I note that Real Time Protocol (RTP, RFC3550; previously RFC1889 published in 1996) had similar needs and solved them at the RTP application layer with sequence numbers and timestamps, and with its RTCP feedback channel.  The two I-Ds that I reviewed did not discuss why this application timing problem cannot be solved at the application layer like RTP solved it.
> 
> I did not see an analysis of forcing an IPv6 fragmentation header (as done by 4rd for transparency, http://tools.ietf.org/html/draft-ietf-softwire-4rd), as that could provide a function nearly identical to the existing (ab)use of IPv4 IPID.
> 
> -d

Well, we can discuss what layer RTP is in; I'm not sure it's application. It's usable by a number of applications. 

I would agree that the requirement to place it in a network layer header has not been established; they could, for example, use the octet sequence number in the TCP header, unless everything above the network layer is encrypted. However, I think it *is* fair to say that putting it lower down the stack makes it readily accessible for more applications or transports more quickly. You have experience with Happy Eyeballs, and the fact that the horrendous design of the socket API forces us to change every application individually when we could have changed the invisible underpinnings of an OS API once, and in so doing ported all of the applications to IPv6 as well. She has a similar problem, but in a packet.

_______________________________________________
v6ops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops