[tcpm] Abolade Gbadegesin's UTO comments at the Paris IETF mtg

Hi,

(was trying to clarify this with Abolade off-list, but I can't track  
an email address down for him; I hope he's lurking or someone can  
forward it to him. I'm interested in other people's feedback on this  
as well, and may send some more messages as I go through the  
remaining UTO issues from Paris.)

Abolade: I'm sorry it has taken me a while to get back to working on  
the UTO draft. You had some interesting comments at the Paris meeting  
that I never responded to. This bit below is from the meeting minutes:

> AG: How does knowing the other end's timeout help me cope with  
> events? All that matters is my own timer.
>
> Knowing the other end's timeout is of no use if I don't know that  
> the other end has begun trying to send something to me. Typically,  
> the only way to know the other end has begun trying to send  
> something is if there's an upper layer protocol which gives me that  
> information. But if I'm relying on an upper layer protocol to tell  
> me when I should be expecting something from the other end, I may  
> as well rely on that upper layer protocol to tell me the timeout as  
> well. And in that case, I don't need UTO in the TCP layer.

Does this accurately summarize your comment? If so, you seem to be  
concerned about the receive timeout (SO_RCVTIMEO sockopt on some  
stacks). This isn't the point of the UTO draft, because AFAIK the TCP  
spec doesn't include this sockopt at all. The UTO drafts is solely  
about the transmit user timout (SO_SNDTIMEO sockopt on some stacks).

The next update will clarify that and also explain that if the stack  
implements something like SO_RCVTIMEO, it also needs adaptation. But  
since that timer is not in the TCP spec (or I am unable to locate  
it), I'm not sure we can change its behavior.

Or am I completely misunderstanding you?

Thanks,
Lars
--
Lars Eggert                                     NEC Network Laboratories

[tcpm] Abolade Gbadegesin's UTO comments at the Paris IETF mtg

Attachment: smime.p7s