Re: [Tsvwg] TCP and UDP MIB issues

[Anders Persson <[e-mail]>]

Gorry Fairhurst wrote:
>
> 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.
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 
> forward from the working groups that maintain the protocols that a MIB 
> relates to.
I will try to get a (short) slot for the next meeting.

Regards,
Anders

> 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
>>>
>>
>>
>>
>