Subject: Re: [Tsvwg] TCP and UDP MIB issues

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 06 Feb 2007 16:19:14 +0000

I agree these new features could be applicable to UDP-Lite, as well as 
UDP. The situation is only different in that we are currently seeking to 
standardise the first MIB for UDP-Lite (preferably simple and therefore 
more likely to be implemented), whereas the UDP MIB has already been 
widely deployed.

What I do not yet know is whether the best approach is to choose one of 
these methods (either 2 or 3) for inclusion as an optional part of the 
proposed UDP-Lite MIB, or whether to await a fix (MIB extension) that 
could apply equally to UDP-Lite and UDP (giving more consistency). 
Unless people really need these features urgently for UDP-Lite, I'd 
suggest a consistent approach is better.

Have you thought about bringing the I-D to the TSV WG for discussion at 
the next IETF, it is often helpful to get feedback on the best way 
forward from the working groups that maintain the protocols that a MIB 
relates to.

Gorry

Anders Persson wrote:

> Gorry,
> 
> The same general issue does seem to appear within the UDP-Lite MIB, 
> which is how to deal with multiple processes using the same UDP-Lite 
> endpoint. For example, on a system using sockets, you can have one 
> socket being shared between multiple processes if the creator of the 
> socket uses fork() to create child processes. However, with the current 
> MIB it is only possible to associate one processes with an endpoint.
> 
> There are at least four ways this could be addressed:
>    (1) Use udpliteEndpointInstance to create multiple entries. 
> Unfortunately, this approach
>         makes it look like multiple independent endpoints, which might 
> be a bit deceiving
>    (2) Make udpliteEndpointProcess part of the INDEX
>    (3) Create a new Identifier object (like tcpEStatsConnectIdEntry), 
> which could then be
>         referenced by other tables. For example, we could then have 
> udpliteProcessTable
>    (4) Create udpliteProcessTable that mirrors the INDEX of 
> udpliteEndpointTable, but adds
>         udpliteEndpointProcess to the INDEX as well :-(
> 
> My personal choice would be (3), as it allows the MIB to be extended in 
> the future.
> 
> Cheers,
> Anders
> 
> Gorry Fairhurst wrote:
> 
>>
>> Generally, the proposed UDP-Lite MIB follows that for UDP (supporting 
>> both multicast and unicast). It does differ in the udpliteEndpointTable:
>>
>> http://tools.ietf.org/wg/tsvwg/draft-renker-tsvwg-udplite-mib-01.txt
>>
>> If there are implications on the UDP-Lite MIB, we'd be pleased to try 
>> to understand what these are, and any ideas of what we should do.
>>
>> Best wishes,
>>
>> Gorry
>>
> 
> 
>

---

From: Anders Persson <[email-masked]>
Date: Wed, 14 Feb 2007 15:36:11 -0800

Gorry Fairhurst wrote:
> UDP. The situation is only different in that we are currently seeking 
> to standardise the first MIB for UDP-Lite (preferably simple and 
> therefore more likely to be implemented), whereas the UDP MIB has 
> already been widely deployed.
>
> What I do not yet know is whether the best approach is to choose one 
> of these methods (either 2 or 3) for inclusion as an optional part of 
> the proposed UDP-Lite MIB, or whether to await a fix (MIB extension) 
> that could apply equally to UDP-Lite and UDP (giving more 
> consistency). Unless people really need these features urgently for 
> UDP-Lite, I'd suggest a consistent approach is better.
If there was consensus that it is a real problem and an agreed upon 
solution existed, I would suggest including the fix. But right now we 
have neither, so taking the "consistent approach" might be the right 
thing to do.
>
>
> Have you thought about bringing the I-D to the TSV WG for discussion 
> at the next IETF, it is often helpful to get feedback on the best way 
I will try to get a (short) slot for the next meeting.

Regards,
Anders

>> socket uses fork() to create child processes. However, with the 
>> current MIB it is only possible to associate one processes with an 
>> endpoint.
>>
>>         makes it look like multiple independent endpoints, which 
>> might be a bit deceiving
>> My personal choice would be (3), as it allows the MIB to be extended 
>> in the future.
>>
>> Cheers,
>> Anders
>>
>> Gorry Fairhurst wrote:
>>
>>>
>>> Generally, the proposed UDP-Lite MIB follows that for UDP 
>>> (supporting both multicast and unicast). It does differ in the 
>>> udpliteEndpointTable:
>>>
>>> If there are implications on the UDP-Lite MIB, we'd be pleased to 
>>> try to understand what these are, and any ideas of what we should do.
>>>
>>> Best wishes,
>>>
>>> Gorry
>>>
>>
>>
>>
>