RE: comments on draft-kashyap-ipoib-connected-mode-02.txt

At 05:54 PM 12/11/2004, Margaret Wasserman wrote:

>Hi Bill,
>
>At 6:53 AM -0800 12/11/04, Bill Strahm wrote:
>>OK - a couple of misconceptions
>
>I am sorry for my limited understanding of Infiniband...  Hopefully we all 
>have enough information between us to reach the right answers here...
>
>>I do not believe there will be a problem however because the timers are
>>on such a different scale.  Let me try and give an example... There are
>>retries in Ethernet (I am talking about collision detection and back
>>off) - What if we decided to worry about TCP retransmitting because the
>>Layer 2 packet hasn't been able to get on the wire and the TCP timers
>>went off and started retransmitting ?  People don't worry because the
>>timers are SO different - this will be even more pronounced in the IB
>>world.
>
>I think I understand your point about timers, but I don't really 
>understand how this works...  Does IB RC actually retransmit lost packets?

Yes.  It uses a strongly ordered protocol to recover all lost packets 
between endnodes.

>Or does it just have some type of collision-detection & back-off 
>mechanism, like Ethernet?

Congestion management is optional but can be applied.

>  If it retransmits, how can it do that without waiting for at least one 
> round-trip-time to know that data has been lost?

Detection is either explicit through the receipt of a NAK or through a 
timer expiring.

>And, if it doesn't retranmit, how can it guarantee reliability if data is 
>lost?

It does retransmit or the connection is terminated with an error.


>Ethernet does not actually retransmit packets... an Ethernet device will 
>detect a collision during transmission of the packet preamble and wait a 
>very short period before trying again.  This time is much shorter than the 
>Ethernet round-trip-time, so it is guaranteed (if I understand this 
>correctly) to be shorter than the smallest possible TCP retransmission 
>timer (which will continuously decrease if things are going well until it 
>gets quite close to the round trip time for the TCP connection).
>
>The fact that Ethernet does not actually retransmit is also important, as 
>you don't need to worry about retransmissions at the Ethernet layer 
>exacerbating a congestion condition.

There are pros / cons to each scheme but at this point the focus is not on 
why IB does what it does but whether this works well for an IP over IB 
solution.


>>I don't think we will be able to move the MTU above 64K - just because I
>>believe the IP packet size is (was ??? Has the size parameter gone up ?)
>>64K so don't worry about someone trying to stick a 2G IP packet onto the
>>wire.  At the same time if it is possible to specify a single IP packet
>>that is 2G, maybe we need some text staying the MTU should be limited to
>>something sane
>
>IPv6 includes a Jumbo Payload hop-by-hop option which allows the 
>transmission of IPv6 packets with payloads of >64K bytes.  RFC 2147 (TCP 
>and UDP over IPv6 Jumbograms) defines how to use TCP and UDP with IPv6 
>Jumbograms.  I don't now if either of these mechanisms is widely 
>implemented, though.

Whether widely or not, they should not be precluded from being supported in 
an implementation.

Mike

_______________________________________________
IPoverIB mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ipoverib