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

["Fred Baker (fred)" <[e-mail]>]

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.