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

["Ackermann, Michael" <[e-mail]>]

I would like to agree with what I believe Fred is saying.   That is, that for those of us that do diagnostics at large DataCenters (EDCO),  the problem resolution needs addressed here span multiple protocols and are not limited to TCP.  

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Fred Baker (fred)
Sent: Saturday, June 01, 2013 10:47 AM
To: Dan Wing (dwing)
Cc: [e-mail]; [e-mail]
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


The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.